SpringBoot+Vue售后服务跟踪系统设计：从数据库建模到部署实战

1. 为什么售后服务跟踪系统是毕设选题的"安全牌"

每年毕设季，都有学弟学妹问我："SpringBoot+Vue的题目都快被做烂了，还能做出花来吗？"我的回答一直是——题目烂不烂不重要，重要的是你能不能把一个业务闭环讲清楚。产品售后服务跟踪系统就是典型的"业务逻辑清晰、技术栈全面、论文好写"的选题。

这个系统解决的核心问题很实在：产品卖出去了，售后工单怎么登记、维修进度怎么跟踪、客户满意度怎么回访、配件更换记录怎么留存。很多中小型制造企业和电商卖家，售后流程还停留在Excel表格甚至纸质单据阶段，一个客户打电话来问维修进度，客服得翻半天聊天记录才能答复。所以这类系统的需求是真实存在的，毕设答辩时你讲"我调研了xx企业的售后流程痛点"，比讲"我实现了一个通用的管理系统"要扎实得多。

从技术角度看，SpringBoot+Vue前后端分离是目前中小型项目的主流标配，也是面试官最熟悉的技术栈。做完这个项目，你等于把Java后端、MySQL数据库、前端工程化、接口联调、服务器部署这几块硬技能全部过了一遍，写进简历里也拿得出手。

这篇文章我会按我实际做这个项目时的顺序来复盘：先讲核心模块和数据库怎么设计，再讲后端接口的实现思路，然后是前端页面和接口对接的要点，最后是部署和论文写作的干货。每一步都会说清楚"为什么这么做"，而不是只丢一堆代码让你自己看。

2. 核心模块拆解与数据库建模：先把地基打牢

很多同学做毕设上来就写代码，写到一半发现表结构不对，又要推倒重来。我强烈建议先把模块边界理清楚，再动手建表。

2.1 系统角色与功能边界划分

售后服务跟踪系统至少要包含三种角色：售后客服（也叫坐席）、维修工程师、系统管理员。如果还想加亮点，可以再加一个"客户自主报修"的入口，让客户通过小程序或者H5页面提交故障描述，这样就覆盖了前后端分离下的多端场景。

• 客服角色：创建工单、派单给工程师、回访客户、记录满意度评价。
• 工程师角色：接收工单、更新维修进度、填写维修结果、登记配件更换信息。
• 管理员角色：维护产品分类和型号、管理员工账号、查看统计报表、处理超时工单。

这三类角色的操作路径非常清晰，天然适合用Spring Security或JWT做权限控制。我在实际项目中用的是JWT+拦截器的方案，没上Spring Security。原因很简单：毕设场景里权限模型只有三种角色，Spring Security的过滤器链和配置体系反而会增加学习成本，答辩时你还要解释一堆和你业务无关的配置。JWT核心代码不超过50行，逻辑一目了然，面试官问起来你也能讲得头头是道。

2.2 数据库表结构设计思路

这一步是整个项目的核心，表建好了，后面的代码就是体力活。我设计了下面这几张核心表：

用户表（sys_user）

工单表（after_sale_order）是整个系统的核心，字段设计直接决定了业务逻辑的复杂度：

维修记录表（repair_record）

回访记录表（visit_record）

配件库存表（parts_stock）是加分项，工程师维修时登记更换配件自动扣减库存，库存低于阈值时管理员能看到预警提醒。这个功能能展示你有多表关联和事务处理的能力，论文里也更有东西写。

2.3 表关系与业务流转

工单表和用户表是外键关联，但我的建议是逻辑外键就好，物理外键能不加就不加。原因有两个：一是MyBatis-Plus查询时用逻辑外键反而更灵活，二是在线演示或者部署到服务器时，物理外键在某些数据库迁移场景下容易出幺蛾子。这次用MyBatis-Plus的LambdaQueryWrapper写条件查询，就是看中它不用写XML，一张工单列表的筛选条件比如状态、时间范围、关键字搜索，用几行链式条件就能写完，对毕设这种开发周期很短的项目来说效率极高。

业务流转的核心逻辑是这样的：客服创建工单后，工单进入"待派单"状态。工程师登录系统后能看到所有待派单的工单，可以选择"认领"，认领后工单变为"维修中"。也可以在列表里让管理员手动指定，适合比较紧急或者需要特定工程师处理的工单。维修完成后，工程师填报维修内容和配件更换信息，工单变为"已完成"。这个时候客服就可以做回访了，回访记录填写完成后工单变为"已回访"并最终关闭。

这个状态机的流转顺序，就是论文里"业务流程设计"部分的框架图。建议你用PlantUML（因为它是文本绘图工具，比拖拽画图效率高很多）先把状态流转图画出来，写论文时直接截图用。

3. 后端接口设计与关键业务实现

后端我用的技术组合是SpringBoot 2.7 + MyBatis-Plus + MySQL 8.0 + JWT。有必要说一下为什么选SpringBoot 2.7，而不是最新的SpringBoot 3.x。原因很现实：很多学校机房和教程用的还是JDK 8，SpringBoot 3.x强制要求JDK 17，如果为了毕业设计特意去配新环境，反而给答辩部署增加变数。用2.7版本，JDK 8跑得稳稳当当，生态也成熟。

3.1 统一响应结构体的设计

前后端分离的项目，后端接口返回的数据格式必须统一，前端才能写一套拦截逻辑。我定义了一个Result类，结构如下：

public class Result<T> { private Integer code; // 200成功 500失败 401未登录 private String message; // 提示信息 private T data; // 数据体 public static <T> Result<T> success(T data) { ... } public static <T> Result<T> error(String msg) { ... } }

所有Controller的返回值都封装成Result，前端Axios拦截器里统一判断code是否为200，不是就走错误提示。这样代码里不会到处都是try-catch的返回值判断，清爽很多。

提到Axios拦截器，顺便说一个我在前端项目里处理接口请求时的习惯：我会在axios的请求拦截器里统一设置token，在响应拦截器里统一处理token过期的问题。这样一个项目中所有的接口请求和响应处理逻辑都收敛在一个地方，不用每个业务页面各自写一套登录状态判断，前端代码会特别干净。这也是前后端分离项目里非常标准的一种做法。

3.2 JWT登录鉴权的完整实现

JWT的流程不复杂：用户登录成功后，后端生成一个token返回给前端，前端每次请求在Header里带上这个token，后端通过拦截器校验token并解析出当前用户信息。关键代码块我给你拆解一下。

先是一个JwtUtil工具类，负责生成和解析token：

@Component public class JwtUtil { private static final String SECRET = "your-secret-key"; private static final long EXPIRE_TIME = 24 * 60 * 60 * 1000; // 24小时 public String createToken(Long userId, String username, String role) { return Jwts.builder() .claim("userId", userId) .claim("username", username) .claim("role", role) .setExpiration(new Date(System.currentTimeMillis() + EXPIRE_TIME)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public Claims parseToken(String token) { return Jwts.parser().setSigningKey(SECRET).parseClaimsJws(token).getBody(); } }

然后是拦截器，在请求进入Controller之前校验token：

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { if ("OPTIONS".equals(request.getMethod())) return true; // 放行跨域预检请求 String token = request.getHeader("Authorization"); if (token == null || token.isEmpty()) { throw new BusinessException(401, "未登录或登录已过期"); } // 解析token并存入request上下文，方便后续获取当前用户 Claims claims = jwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); return true; } }

注册拦截器时，需要放行登录接口和静态资源路径，其他所有接口都要过这道校验：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(jwtInterceptor) .addPathPatterns("/api/**") .excludePathPatterns("/api/auth/login", "/api/auth/register"); } }

这里我踩过一个坑：前端开发模式下用的是Vite的8080端口，后端是SpringBoot的9090端口，跨域请求的预检OPTIONS请求如果不放行，前端会报跨域错误而且很难排查。加一行if ("OPTIONS".equals(request.getMethod())) return true;就能解决。这个细节面试官问到跨域处理时，你主动提出来会很加分。

3.3 工单派单与状态流转的并发思考

工单模块是整个系统里最需要注意并发问题的部分。举个实际场景：一个待派单的工单，可能会被两个工程师同时点击"认领"。如果不用任何限制，两个人都会认领成功，工单的assignee_id被覆盖，数据就乱了。

我的解决方案是用UPDATE ... WHERE status = 0的乐观锁思路：

@Update("UPDATE after_sale_order SET status = 1, assignee_id = #{engineerId}, " + "update_time = NOW() WHERE id = #{orderId} AND status = 0") int claimOrder(Long orderId, Long engineerId);

这个方法返回int值，如果返回0说明工单状态已经不是待派单了，说明被别人先认领了，这时候就提示"该工单已被其他人认领"。用这种update语句带条件的方式做并发控制，比先查询再更新要安全得多，而且代码量极小。

工单状态流转的整个链路，建议在Service层写清楚一处，每层状态变化时都用带条件更新的方式实现，保证状态并发下的正确性。这也是毕设论文中可写"并发控制与数据一致性设计"章节的基础。

3.4 核心查询场景的SQL写法

售后服务系统的高频查询场景基本都是列表加筛选。比如客服要查"最近一个月未回访的已完成工单"，工程师要看"分派给我且尚未完成的工单"，管理员要按产品型号统计维修数量。这类需求，MyBatis-Plus的LambdaQueryWrapper写起来非常舒服。

给一个工单列表分页查询的示例：

@Override public PageResult<OrderVO> queryOrderPage(OrderQueryDTO dto) { Page<AfterSaleOrder> page = new Page<>(dto.getPageNum(), dto.getPageSize()); LambdaQueryWrapper<AfterSaleOrder> wrapper = new LambdaQueryWrapper<>(); // 按状态筛选 if (dto.getStatus() != null) { wrapper.eq(AfterSaleOrder::getStatus, dto.getStatus()); } // 按客户姓名模糊查询 if (StringUtils.isNotBlank(dto.getCustomerName())) { wrapper.like(AfterSaleOrder::getCustomerName, dto.getCustomerName()); } // 按创建时间区间查询 if (dto.getStartTime() != null && dto.getEndTime() != null) { wrapper.between(AfterSaleOrder::getCreateTime, dto.getStartTime(), dto.getEndTime()); } // 按工程师筛选 if (dto.getEngineerId() != null) { wrapper.eq(AfterSaleOrder::getAssigneeId, dto.getEngineerId()); } // 按角色限制数据范围 if ("ENGINEER".equals(dto.getRole())) { wrapper.eq(AfterSaleOrder::getAssigneeId, dto.getCurrentUserId()); } wrapper.orderByDesc(AfterSaleOrder::getCreateTime); Page<AfterSaleOrder> result = orderMapper.selectPage(page, wrapper); // 转VO并填充用户名等关联信息 return convertToPageResult(result); }

这里有个经验：查询条件一定要用DTO对象封装，不要直接在Controller接收一堆零散的参数。DTO可以让参数结构清晰，纸上谈兵也能，但更重要的是为后续扩展留余地，比如筛选条件增多时不需要改方法签名。答辩时老师看到DTO、VO分层明确，通常会在设计规范上给不错的印象分。

4. 前端工程化实现：Vue3 + Element Plus的完整落地

前端我用的是Vue3 + Vite + Pinia + Element Plus + Axios这一套。早两年可能还会用Vue2，但2025年了，Vue3已经是绝对主流，Vite的启动速度和开发体验也远好于Webpack。面试的时候新版技术栈写在简历上是加分项，至少说明你有主动跟进主流技术。

4.1 环境配置与工程初始化

讲真，我觉得Vue脚手架搭建这块最值得说的其实不是Vite怎么初始化，而是安装依赖时容易踩的坑。安装依赖用npm install时，有时候前端项目会因为依赖版本冲突报错，我自己的经验是这样：直接删除node_modules和package-lock.json，然后重新install，绝大多数情况下都能解决。另外Vite项目启动时默认端口是5173，如果被占用，可以在vite.config.js里指定其他端口：

// vite.config.js import { defineConfig } from 'vite' import vue from '@vitejs/plugin-vue' export default defineConfig({ plugins: [vue()], server: { port: 8080, proxy: { '/api': { target: 'http://localhost:9090', changeOrigin: true } } } })

配置了devServer的proxy转发之后，前端代码里所有的请求路径直接写/api/xxx就行，不用写完整的http://localhost:9090。这样做的好处有两个：一是开发环境不用处理跨域（代理转发绕过了CORS限制），二是等部署到生产环境时，Nginx只需要做同样的转发配置，前端代码一行都不用改。

4.2 路由设计：权限控制的第一次拦截

前端路由用vue-router，配合后端返回的角色信息做动态权限控制。路由表分为两层：公共路由和需要登录才能访问的权限路由。公共路由只有登录页和注册页，其他所有业务页面都挂在Layout组件下。

我的做法是写一个路由守卫：

// router/index.js router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path === '/login') { next() return } if (!token) { next('/login') return } // 权限校验：根据角色判断是否可以访问 const role = localStorage.getItem('role') if (to.meta.roles && !to.meta.roles.includes(role)) { next('/403') return } next() })

一个值得优化的点是：把token和用户信息统一放到Pinia里管理，同时做持久化，刷新页面时从localStorage恢复。这样状态管理清晰，组件里也方便获取用户信息。

4.3 工单管理页面的完整实现

工单列表页面是这个项目前端最重要的页面，也是代码量最大的一个组件。我用Element Plus的el-table和el-card组合，典型的后台管理页面布局。核心逻辑分几块：搜索区、表格区、分页器、操作按钮。

表格操作按钮的关键是每个工单行按照不同状态显示不同的操作项：

• 待派单：在工程师端显示"认领"，在管理员端显示"指派"
• 维修中：在工程师端显示"填写维修记录"
• 已完成：在客服端显示"回访登记"

用Element Plus的el-table-column配合作用域插槽（template #default）很灵活：

<el-table-column label="操作" width="220"> <template #default="{ row }"> <el-button v-if="row.status === 0 && role === 'ENGINEER'" type="primary" size="small" @click="claimOrder(row)"> 认领 </el-button> <el-button v-if="row.status === 1 && (role === 'ENGINEER' && row.assigneeId === userId)" type="warning" size="small" @click="openRepairDialog(row)"> 维修记录 </el-button> <el-button v-if="row.status === 2 && role === 'SERVICE'" type="success" size="small" @click="openVisitDialog(row)"> 回访 </el-button> </template> </el-table-column>

这里需要注意的条件比较多，刚上手时容易把v-if逻辑写乱。我的建议是先画一个状态操作矩阵（表格：行是状态，列是角色，交叉点写允许的操作），理清楚了再写模板代码。这个矩阵画出来之后还有一个好处——可以直接放到论文的"系统功能设计"部分当插图。

4.4 Axios封装与动态表单校验

前端接口调用统一走封装好的request.js模块。这个模块做了几件事：注入token、统一错误提示、处理后端返回的code值、拦截401自动跳转登录页：

// utils/request.js import axios from 'axios' import { ElMessage } from 'element-plus' import router from '@/router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = token } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code === 200) { return res.data } else if (res.code === 401) { localStorage.removeItem('token') router.push('/login') return Promise.reject(new Error('登录已过期')) } else { ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } }, error => { ElMessage.error('网络错误，请检查后端服务是否启动') return Promise.reject(error) } ) export default request

表单校验这个环节我提一下动态规则：工单创建表单里，维修费用、更换配件等字段只有在特定状态下才出现，对应的校验规则也是动态增减的。Element Plus的Form组件的rules支持通过:rules="formRules"动态绑定，你可以根据不同场景计算这个对象。做好这一步，不仅前端体验流畅，后端也不用操心"这个字段为什么空了"。

5. 从本地到服务器：打包部署与常见坑

很多同学的毕设做完了，代码能跑，但一部署到服务器或者演示环境就拉胯。其实部署没多难，关键是别慌，按步骤来。我用的方案是前后端分离部署：后端打包成jar直接跑，前端打包成静态文件放在Nginx下并且用Nginx转发API请求。

5.1 本地打包的正确姿势

后端打包，先确认pom.xml里packaging是jar，然后执行：

mvn clean package -DskipTests

这里有个最常见的坑：SpringBoot多模块项目时，子模块A依赖子模块B，但B没有安装到本地Maven仓库，打包A就会报找不到依赖。解决办法是先对B执行mvn install，再打包A。如果是单模块项目基本不会有这个问题。生成target目录下的jar后，验证一下：

java -jar after-service-0.0.1-SNAPSHOT.jar --server.port=9090

前端打包很简单：

npm run build

生成dist目录，里面是纯静态文件。注意如果后端API地址是/api开头且没有写死完整域名，这里的构建产物可以直接扔到Nginx里用，不然还要改环境变量重新构建。

5.2 Nginx配置与反向代理

生产环境我依然用Nginx做反向代理，配置如下：

server { listen 80; server_name your-domain.com; # 前端静态资源 location / { root /usr/share/nginx/html; try_files $uri $uri/ /index.html; } # 后端API代理 location /api/ { proxy_pass http://localhost:9090/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

这里有个精细的小点：proxy_pass http://localhost:9090/api/这个路径末尾的斜杠在Nginx里会替换匹配到的/api/前缀，如果后端接口路径是/api/auth/login，会正确转发到http://localhost:9090/api/auth/login。如果proxy_pass不带斜杠则会把/api原样带过去。这个小细节不注意可能造成404，排查时要想到。

前端路由用的是history模式，刷新某个子路由页面会404，try_files $uri $uri/ /index.html就是解决这个问题的：找不到文件时一律返回index.html，让Vue Router接管路由。

5.3 Docker部署的额外加分项

如果你想让项目在答辩演示时更稳定，可以考虑把后端和MySQL都用Docker容器跑。写一个简单的docker-compose.yml：

version: '3' services: mysql: image: mysql:8.0 ports: - "3306:3306" environment: MYSQL_ROOT_PASSWORD: root123456 MYSQL_DATABASE: after_sale_db volumes: - ./mysql-data:/var/lib/mysql backend: build: ./backend ports: - "9090:9090" depends_on: - mysql environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/after_sale_db

用Docker Compose的好处是：演示之前一条docker-compose up -d就能把数据库和后端服务全部拉起来，不用现场配置MySQL连接、初始化数据。我见过太多答辩现场因为本机MySQL密码不对或者数据库没初始化导致项目起不来的尴尬情况，用Docker能直接规避掉。

我自己的建议是Docker熟练的话就上，不熟练的话不要硬上，因为你答辩时老师可能会问Docker的原理，答不上来反而扣分。稳扎稳打用本地部署也完全够格。

5.4 部署后的验证清单

部署完成之后，一定要按这个顺序过一遍：

1. 打开首页，确认前端能加载，没有白屏。
2. 登录页输入正确的账号密码，确认能跳转主页。这里最容易漏的是后端服务没起来，导致登录接口超时。
3. 刷新任意一个子页面（比如刷新一下工单列表），确认前端路由没有404。
4. 提交一个新工单，走一遍完整的流程：创建→派单→维修→回访。
5. 看后端日志，确认没有报错堆栈。

这套验证清单看着简单，但能帮你提前发现大部分现场演示时的翻车点。

6. 不止是代码：论文结构和答辩准备的实用建议

很多时候毕设做完了，代码没问题，但论文写不出来，或者答辩时讲不清楚。这个项目因为业务逻辑清晰、技术栈通用，论文写起来其实有套路可循。

6.1 论文章节怎么排

推荐结构是这样的：

• 第一章绪论：写背景和意义时，从"售后服务是企业竞争力的重要组成部分"切入，再结合国外服务管理理论和国内企业售后现状，引出系统开发必要性。这部分可以引用一点服务管理相关的文献，但不要写太深，点到为止。
• 第二章相关技术介绍：SpringBoot、Vue、MyBatis-Plus、MySQL每个技术写两段，一段介绍基本概念，一段说明为什么选它用于本项目。特别建议写清楚MyBatis-Plus相较于传统MyBatis在开发效率上的优势——这也为你后面的代码实现做铺垫。
• 第三章需求分析：画出用例图（客户端、客服端、工程师端、管理端四个角色），每个角色列出用户故事。特别要说清楚工单状态流转的需求，比如哪些操作会引起哪些状态变化。
• 第四章系统设计：重点画系统架构图（前后端分离架构、Nginx反向代理、数据交互流向）和数据库ER图。时序图可以画工单创建时序、登录鉴权时序，这两个是最核心的交互场景。
• 第五章系统实现：不要把代码整段贴上，要用"业务+流程+关键代码片段"的方式，每个功能模块先讲业务规则，再配一段核心代码，加上运行截图，图文配合效果好很多。
• 第六章系统测试：可以简单区分功能性测试和非功能性测试。功能测试写几个核心用例表格（测试步骤、输入数据、预期结果、实际结果、是否通过），非功能测试可以写并发认领工单的测试结果，体现考虑数据的稳健性。
• 第七章总结与展望：写自己完成的重点工作和不足，这部分要真诚，不要空喊口号。展望部分可以写"未来可以考虑接入企业微信通知"或者"集成大模型能力做智能故障分析"，一个实实在在的方向比空泛的大数据云计算接地气得多。

6.2 答辩演示的演示顺序

答辩时不要一上来就点开源码，先讲清楚业务。我建议的演示路径是：登录页用管理员账号登录，创建几个测试工单和用户，然后切换客服账号演示工单创建和派单，再切换到工程师账号演示认领和维修，最后用客服账号回访。通过切换账号，清晰展示三类角色的功能边界和权限控制。

事先把测试数据准备充分，各种状态的工单各放几条，演示时按状态筛选展示，既有说服力又不会临场慌乱。

6.3 常见答辩问题的准备

老师最爱问的几个问题，提前准备好答案很重要：

"数据库为什么用逻辑外键？"——可以答为降低开发复杂度，业务层维护关联关系更灵活，同时避免了物理外键带来的删除和性能问题。

"JWT和传统Session有什么区别？"——从无状态扩展性切入，JWT不需要在服务端存储会话，适合分布式场景。顺势说出token失效策略的考量、在拦截器里如何校验及处理过期。

"前后端分离和传统单体架构有什么优缺点？"——可以讲传统单体开发简单部署方便，但是前后端代码耦合程度高、团队并行开发和维护成本高；前后端分离简化团队协作、职责清晰、也可以独立并发发展前端和后端的构建部署。最好结合你的开发经历讲体会，显得是真做过而不是背的。

"系统如何保证数据安全？"——除了登录接口之外，密码加密存储、接口鉴权、跨域限制都要提到。简单一句话就能答上："密码通过BCrypt加盐加密存储，接口通过JWT拦截器统一鉴权，前端生产环境通过Nginx只暴露80端口，数据库不对外开放。

7. 做完这个项目之后

回顾整个项目过程，"做完"和"跑通"其实是两件事。跑通容易，跟着教程把环境搭好、代码拉下来、启动按钮一按，三分钟的事。做完意味着你能对着自己的代码讲清楚每一个模块为什么这么设计，每一个表为什么有这些字段，每一个接口返回什么结构。这个系统本身难度不高，但正因为业务逻辑完整清晰，反而给了你充足的空间去展示工程化思维和细节把控能力。

如果你时间充裕，在完整的售后服务跟踪流程之外，其实还有几个不错的扩展方向可以做：给客服端加一个定时任务，统计超时未处理的工单并自动提醒；增加客户自主报修后的短信或邮件通知；或者把回访满意度数据做成图表看板，用来辅助质量管理决策。这些都不需要换技术栈，在现有项目上加功能就行，但每加一个，论文和答辩的说服力就上一个台阶。

你可以把它当作业做完交差，也可以把它当成自己简历上一个能讲清楚、能扛得住追问的实战项目。这中间的差别，就看你在部署完那一刻之后，还愿不愿意多花几天时间，把它真正弄明白。