简介：这套基于 Java+SSM+Vue+MySQL 的工单管理系统，定位为高分毕业设计项目，适合计算机相关专业学生用于毕设、课程设计或期末大作业。系统包含前后端完整源码、数据库脚本与配套工具，经导师指导与严格调试，配置 MySql8.0、Tomcat 7/8、Maven 环境后即可运行，功能覆盖工单流转、用户管理等常见业务场景。资源包为 zip 格式，共含 1001 个文件，以 js、css、html 等前端页面文件、java 后台逻辑文件、jsp 动态页面和 sql 数据库脚本为主，另有 png/gif 图片素材与字体图标；包体约 10.46MB，轻量易部署。数据库可使用 Navicat 管理，适合在 IDEA 中导入学习。目前已有 177 人学习下载。借助项目内附的数据库脚本与完整目录结构，读者可快速理清 SSM 与 Vue 的整合思路，理解工单流转和用户管理的实现方式，为二次开发或毕业设计答辩提供直接参考。

1. 引言：工单靠微信群接单，这个选题是怎么变成毕业设计的

做运维和客服管理的同学应该都有体会：工单一旦多了，微信群接单、Excel 记进度的方式就会彻底失控。同一个故障被三个人重复上报，处理到哪一步没人说得清，月底统计工作量全靠手工数聊天记录。某高校的信息中心每学期要处理上千条校园报修，负责老师最常说的一句话就是“这个事到底谁在处理，给我一个准信”。这个基于 Java + SSM + Vue + MySQL 的工单管理系统，解决的正是这个问题：把工单的创建、分派、处理、关闭全流程收进系统里，让每一条工单都有责任人、有时间节点、有处理记录。它适合两类人：一类是拿它当毕设或课设的学生，前后端完整、能跑通、有数据库脚本，交上去可以直接答辩；另一类是真正需要一套轻量工单管理方案的开发者，用 SSM 这种经典框架做后台，用 Vue 做前端，结构清晰，改一改就能落地到实际的运维场景中。

2. 总体架构设计：SSM + Vue 前后端分离与六大模块的职责划分

2.1 技术选型：为什么是 SSM 而不是 Spring Boot

很多同学拿到这个项目的第一反应是：现在新项目不都用 Spring Boot 吗，为什么这个课题还选 SSM？这个问题的答案本身就是答辩的加分点。SSM 指的是 Spring + SpringMVC + MyBatis 三件套，它比 Spring Boot 更“裸”，框架之间的装配关系都是显式写在配置文件里的，适合在学习阶段把 IoC 容器、AOP 切面、事务管理、SQL 映射这些底层机制看清楚。而 Spring Boot 把大量配置自动化了，写起来快，但很多细节被黑匣子化，答辩时如果被问到“SpringMVC 的请求流程是怎样的”，用 SSM 项目的经验回答会更扎实。

从部署环境也能看出这个项目的定位：Tomcat 建议 7.x 或 8.x，配合 Maven 做依赖管理，这是 SSM 时代最标准的组合。MySQL 用 8.0，数据库工具用 Navicat，开发环境用 IDEA。整套技术栈在高校的实验环境里兼容性最好，不会出现 JDK 版本和框架版本互相打架的情况。这里有个经验：如果你的机器上 JDK 是 1.8，Tomcat 就别用 9.x，否则 Servlet 版本不兼容，项目跑不起来的时候你根本不知道问题出在哪。

2.2 整体结构：前端 Vue 与后端 SSM 如何分工

系统从物理上分成两个部分：前端是一个 Vue 单页应用，负责页面渲染和交互；后端是 SSM 框架提供的 RESTful API，负责业务逻辑和数据持久化。两者通过 JSON 通信，前端用 Axios 发请求，后端返回统一格式的结果对象。前后端分离的好处是职责边界清楚：改工单列表的样式不用碰 Java 代码，改状态流转的逻辑不用动页面模板。

后端的包结构一般按三层架构来分。Controller 层只做参数接收和结果封装，不写业务逻辑；Service 层处理具体业务，比如工单分派时要判断当前操作人是否有分派权限、目标处理人是否存在；Mapper 层用 MyBatis 写 SQL，负责和数据库打交道。部分参考实现还在 Service 和 Mapper 之间加了一层 VO 转换，把数据库实体和前端展示对象分开，避免直接把 password 字段序列化返回给前端。

前端的 Vue 项目一般用 vue-router 做路由，用 Vuex 或 provide/inject 做全局状态管理。页面按功能模块拆组件：登录页、工单列表、工单详情、工单创建、用户管理、数据统计。组件内部维护自己的数据状态，通过 props 和 events 与父组件通信。需要说明的是，这个项目没有引入 Element UI 这类重型组件库，样式用的是项目自带的 layui.css、bootstrap.css 和 animate.css，整体风格偏向后台管理系统的经典布局——左侧菜单、右侧内容区，这对课程设计来说反而是优点：不依赖 CDN 资源，离线也能跑。

2.3 数据库设计：工单主表与用户、日志、统计的关联关系

数据库是这个项目最值得讲的部分。核心表一般不少于五张：用户表、工单表、工单状态流转日志表、通知消息表、角色权限表。用户表设计上要区分普通用户、处理人、管理员三种角色，不能只靠一个 isAdmin 字段，因为后期要扩展到多角色时一张表会改得很痛苦。通常的做法是建一张 role 表，再用 user_role 关联表把用户和角色连起来。

工单表是绝对的主表，字段设计要覆盖完整生命周期。主键用自增 id，title 存工单标题，description 存详细描述，type 区分报修类型，priority 分紧急程度，status 字段是状态机的心脏——建议用 int 存状态码而不是直接存字符串，比如 0 待分派、1 已分派、2 处理中、3 已完成、4 已关闭，这样写 SQL 统计时效率更高，也避免中英文混存造成的数据不一致。还要有 create_by、assign_to、handle_by 三个用户关联字段，分别记录创建人、被分派人和实际处理人。时间字段 create_time、update_time、finish_time 一套齐全，方便做超时告警。

状态流转日志表容易被初学者忽略，但有经验的开发者一定会建。它记录每一次状态变化的操作人、操作时间、变更前后的状态值，这份数据在答辩时是“系统健壮性”的强证据：老师问“如果工单处理到一半发现分派错了怎么办”，你可以回答“系统记录了完整的流转轨迹，可以追溯到每一次误操作”。

3. 核心模块实现：从登录鉴权到工单状态机的完整链路

3.1 登录与权限控制：拦截器 + Session + 角色校验三层防线

登录模块最忌讳的是只在页面上做判断——前端隐藏一个按钮任何人都能通过改接口绕过。通常的做法是后端做三层防护。第一层是 SpringMVC 的拦截器，注册时拦截所有 /api/ 下的请求，除了登录接口和静态资源，其他请求必须校验 Session 中是否存在用户信息。第二层是角色校验，在 Service 层判断当前用户是否有执行某操作的权限，这里我一般会写一个 @RequireRole 注解配合 AOP 切面，但作为课设项目，直接在 Service 方法里写一个 checkPermission(user, role) 工具方法更直观，也更容易讲解。

前端对应做的是路由守卫。Vue Router 的 beforeEach 钩子里检查 localStorage 中的 token，没有就重定向到登录页。登录成功后把用户信息和角色存进 sessionStorage，菜单的显示根据角色动态渲染：普通用户只看得到“我的工单”，处理人看得到“待处理列表”，管理员全部可见。这样前后端双重拦截，答辩时能解释清楚“为什么说这个系统有安全性设计”。

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口和静态资源，其余一律校验登录态 String uri = request.getRequestURI(); if (uri.contains("/login") || uri.startsWith("/static/")) { return true; } Object user = request.getSession().getAttribute("loginUser"); if (user == null) { // 未登录返回 401，前端收到后跳转登录页 response.setStatus(401); response.setContentType("application/json;charset=UTF-8"); response.getWriter().write("{\"code\":401,\"msg\":\"未登录或会话已过期\"}"); return false; } return true; } }

这段代码里有两个容易被忽略的细节。第一个是 getSession(false) 和 getSession() 的区别，拦截器里应该用 false 的版本，避免为每一个静态请求都创建一个无用 Session。第二个是 response 的编码设置，很多项目在拦截器返回 JSON 时中文乱码，就是因为漏了 setContentType 这一行。

3.2 工单状态机：从待分派到已关闭的流转约束

工单系统的核心价值不在增删改查，而在状态流转的控制。如果用户能直接把一个“已完成”的工单改回“待分派”，那系统就失去了可信度。状态机设计上，我用一个 Map 定义允许的转移路径，每次更新状态前先校验从当前状态到目标状态是否合法。

允许的流转关系如下：待分派可以被管理员分派为已分派；已分派的工单被处理人接单后进入处理中；处理中完成处理后进入待验收，也就是已完成；已完成由创建人确认关闭，进入已关闭。特殊情况是待分派和已分派状态下，创建人可以撤回工单直接关闭；已关闭的工单不允许任何修改，只能查看。这个设计参考了 ITIL 的工单生命周期思想，答辩时能说出这一句会很加分。

public class WorkOrderStateMachine { private static final Map<Integer, List<Integer>> TRANSITIONS = new HashMap<>(); static { // 状态码：0待分派 1已分派 2处理中 3已完成 4已关闭 TRANSITIONS.put(0, Arrays.asList(1, 4)); TRANSITIONS.put(1, Arrays.asList(2, 4)); TRANSITIONS.put(2, Arrays.asList(3, 4)); TRANSITIONS.put(3, Arrays.asList(4)); TRANSITIONS.put(4, Collections.emptyList()); } public static boolean canTransit(int from, int to) { return TRANSITIONS.getOrDefault(from, Collections.emptyList()).contains(to); } public static void updateState(WorkOrder order, int targetState) { if (!canTransit(order.getStatus(), targetState)) { throw new IllegalStateException("非法的状态流转: " + order.getStatus() + " -> " + targetState); } // 状态变更必须写日志，这一步常被漏掉 order.setStatus(targetState); order.setUpdateTime(new Date()); } }

为什么用 Map 而不是在 Service 里写一堆 if else？因为状态流转规则是集中的、可读的、易维护的。将来要加一个“驳回”状态，只需要改这一张表，不需要去业务代码里到处找散落的判断。另外一个经验是：状态变更的日志要和状态更新放在同一个事务里，否则日志缺失会导致追责时没有证据。MyBatis 里用 @Transactional 注解即可，一个方法搞定。

3.3 工单分派逻辑：抢单还是指派

分派是这个系统里业务味道最重的模块。处理方式有两种：管理员手动指派，或者处理人主动抢单。参考实现里做得比较完整的是两者都支持。手动指派时管理员下拉选择处理人，系统校验该用户是否为处理人角色，然后更新 assign_to 字段并生成一条通知消息。抢单模式下，待分派的工单会出现在“待抢单”列表里，处理人点击接单，系统乐观锁更新状态，防止两个人同时抢到同一张工单——这个并发问题的处理在答辩时是亮点。

乐观锁的做法不复杂：工单表增加一个 version 字段，更新 SQL 里带上 version = #{oldVersion} 的条件，如果影响行数为 0，说明被别人抢先，提示“工单已被接单”。这里很多人第一次写会踩坑：用 updateById 时忘掉加 version 条件，导致并发测试时两张单被同一个人抢到。MyBatis 的 update 语句要手写 set version = version + 1 where id = #{id} and version = #{version}，用框架自带的乐观锁插件虽然省事，但答辩时说不清原理。

4. 关键功能落地：Vue 组件通信、通用返回体与统计报表

4.1 前端组件设计：工单列表为何用 table 组件而非手写 DOM

前端部分看起来是简单的页面渲染，但组件怎么拆分、状态怎么管理，直接影响后期维护成本。参考实现里把工单列表做成了一个独立的 WorkOrderTable 组件，接收 props 里的 data 数组和 columns 配置，内部维护 loading、selectedRows、pageNum、pageSize 等状态。父组件负责从后端拉数据、传给子组件，子组件只负责渲染和触发事件。这样拆的好处是，新增一个“我的已关闭工单”页面，只需要复用 WorkOrderTable 组件，传入不同的数据源即可。

列表页的分页是另一个容易出问题的点。很多初学者把分页参数写死在前端，点第二页时直接从全量数据里切，数据量一大页面就卡。这个项目的分页是后端完成的：前端传 pageNum 和 pageSize，MyBatis 用 PageHelper 插件生成 limit 语句，返回结果里包含 total 总数。PageHelper 的使用有个注意点：它依赖 ThreadLocal，所以 startPage 方法必须紧跟要执行的查询语句，中间不能夹别的数据库操作，否则分页会应用到错误的 SQL 上。这个现象在项目中很常见，属于典型的“配置对了但用法错了”。

// 工单列表组件中请求数据的核心方法 loadData() { this.loading = true axios.get('/api/workorder/list', { params: { pageNum: this.pageNum, pageSize: this.pageSize, status: this.statusFilter, keyword: this.keyword } }).then(res => { // 后端通用返回结构 { code: 200, data: { list, total } } if (res.data.code === 200) { this.tableData = res.data.data.list this.total = res.data.data.total } else { this.$message.error(res.data.msg) } }).finally(() => { this.loading = false }) }

这段代码里 finally 的用法值得注意——不管请求成功还是失败，loading 都必须复位，否则页面会一直转圈。另一个细节是请求参数里没有直接用 res.data 而是先判断 code，这是因为后端约定统一返回体，code 为 200 才代表业务成功。有些同学直接判断 HTTP 状态码，结果后端返回 200 但业务失败时，前端弹不出错误提示。

4.2 后端统一返回体与全局异常处理

接口的返回结构如果不统一，前端每个请求都要写不同的解析逻辑，代码会非常冗余。这个项目定义了一个 Result 类，包含 code、msg、data 三个字段。成功时 code 为 200，失败时 code 为业务错误码，比如 401 未登录、403 无权限、500 系统异常。前端 Axios 的响应拦截器里统一处理 code 不等于 200 的情况，弹错误提示并跳转。

全局异常处理用 @ControllerAdvice 注解实现。异常分两类：业务异常和系统异常。业务异常在 Service 里手动抛出，比如“工单不存在”“状态流转非法”“用户名已存在”，由全局异常处理器捕获后转成带提示信息的 Result 返回；系统异常是 NullPointerException 这类意外错误，统一返回“系统繁忙，请稍后重试”，同时把异常堆栈打印到日志里，方便排查。这里的关键是不要在 Controller 里 try catch 业务异常——那会让代码里布满重复的异常处理块，也容易漏掉某个分支。把异常处理集中到一个地方，Controller 的每一个方法都只保留业务逻辑。

4.3 统计报表：用一条 GROUP BY 语句撑起图表页

工单统计页是这个项目里视觉上最出效果的部分。它展示两个数据：各部门工单数量分布、各状态工单占比。后端接口只有两个，每个都是简单的 SQL 查询，然后用 echarts 绘制柱状图和饼图。答辩时老师通常会问“统计数据是不是实时算的”，答案是实时的——没有引入额外的统计表，每次请求都实时聚合。

-- 按状态统计工单数量 SELECT status, COUNT(*) AS order_count FROM work_order WHERE create_time >= #{startTime} GROUP BY status ORDER BY status;

这看起来很简单，但有一个细节值得讲：GROUP BY 之后 MyBatis 怎么映射到实体。通常的做法是在 Mapper 接口里定义 Map 类型作为返回值，或者专门建一个 StatisticVO 类。我一般推荐后者，因为 Map 取出数据后还要手动转类型，写 SQL 时把 status 字段直接映射成名为 statusName 的字符串，用 CASE WHEN 转换一次，前端拿到直接就能用。

统计接口的另一个设计点是图表的空数据占位。如果某个时间范围内没有工单，GROUP BY 的结果为空集合，前端 echarts 会显示空白。常规做法是后端在返回前补齐缺失的状态数据，把数量置为 0。前端做兼容也可以，但放在后端处理更合适，因为这属于业务语义的一部分：状态全集是确定的，缺失即为零。

5. 避坑指南：工单系统开发中最容易翻车的六个问题

5.1 数据库连接配置导致的中文乱码与连接失败

现象：项目启动后访问接口，控制台报“Unknown database”或者页面上显示的中文全部变成问号。原因：数据库连接 URL 里没有设置 useUnicode=true 和 characterEncoding=utf8，导致连接时默认使用系统字符集；或者 Navicat 建库时选错了字符集。解决：连接串写成 jdbc:mysql://localhost:3306/work_order?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai，建库时统一 utf8mb4。MySQL 8.0 还需要显式设置 serverTimezone，否则启动时会报时区错误。这是一个最没有技术含量但出现频率最高的坑，每次都有人栽在这里。

5.2 MyBatis 的 mapper 接口与 XML 绑定失败

现象：启动时提示 Invalid bound statement (not found)。原因：要么是 mapper 接口和 XML 文件没有放在同一个包路径下，要么是 XML 文件的 namespace 和接口全限定名不一致，要么是 Maven 打包时把 XML 文件过滤掉了。第三种原因最隐蔽，因为开发环境能跑，打成 war 包部署到 Tomcat 后就报错。解决：pom.xml 里显式配置 resources 节点，把 src/main/java 下的 .xml 文件也打包进去。这是一个典型的环境与代码分不清的黑匣子问题，排查时先看 target 目录里有没有 XML 文件，高效得多。

5.3 前端跨域导致请求发不出去

现象：浏览器控制台报 CORS error，接口在 Postman 里能通，在页面上不通。原因：前后端分离部署时端口不同，浏览器的同源策略拦截了跨域请求。解决：在后端配置一个 CorsFilter 过滤器或者用 SpringMVC 的 @CrossOrigin 注解。这里有一个需要特别说明的点：只配置前端代理不算解决跨域，上线部署后前端无法代理后端地址时还是会出问题。要同时处理后端跨域配置和前端代理两种方案，但临时调试用后端过滤器更快。

5.4 状态更新丢失 version 条件导致的并发问题

现象：测试时两个处理人同时打开同一张待分派工单，A 先接单成功，B 再提交时系统没有提示，直接把 A 的处理记录覆盖了。原因：更新语句用的是无条件 update by id，没有校验 version 字段。解决：参考 3.3 节的做法，在更新 SQL 里带上 version 条件，并在 Service 层接收影响行数，为 0 时手动抛出业务异常。这个问题的隐蔽之处在于它只在并发的瞬间出现，单测很难复现，必须做并发压测才能暴露。

5.5 文件上传功能没有限制大小导致的服务崩溃

现象：用户上传一个超大附件时，接口长时间无响应，最终 Tomcat 报 OutOfMemoryError。原因：配置文件没有设置上传大小限制，同时业务逻辑里把附件读入了内存而不是流式写入磁盘。解决：springmvc.xml 里配置 multipartResolver 的 maxUploadSize 限制在 10MB 以内，同时把文件流的处理方式从 byte[] 改为 FileOutputStream 边读边写。虽然工单管理系统的附件需求不重，但答辩时如果系统有这个功能，这一条是老师常问的点。

5.6 测试数据只有几条，统计图表效果单薄

现象：系统跑通了，但统计页面只有两三根柱子，答辩时视觉上撑不住场面。原因：数据库脚本里只导入了结构没有导入足够的示例数据。解决：写一段数据生成脚本，循环插入几百条工单记录，日期分布在最近三个月内，状态和部门也尽量分散。注意生成测试数据时要把外键关系照顾到位，不能出现工单关联到不存在的用户。数据量一多，列表分页和统计图表的展示效果就都出来了，这也算是一种最不费力的优化。

6. 验收与答辩：从功能测试到演示链路的设计方法

6.1 功能验收清单：跑一遍就知道能不能交

验收这个项目，我用一张清单对照着过。第一类是基础功能：登录成功、登录失败提示、退出登录、未登录访问被拦截，这四条覆盖了权限模块。第二类是工单主流程：创建工单、管理员分派、处理人接单、填写处理结果、状态变更为已完成、创建人确认关闭，走完这一步说明状态机是通的。第三类是异常流程：分派给不存在的人、重复接单、撤回已关闭的工单，系统都必须给出明确提示而不是报 500。第四类是统计与查询：按状态筛选、按关键字搜索、分页切换、统计图数据与列表数据一致。

走清单时要特别注意两点。一是用不同的角色各注册一个账号，分别走一遍流程，避免所有操作都用管理员账号测试，导致普通用户的权限漏洞没被发现。二是清空浏览器缓存后再测一遍登录流程，有些前端改动后没刷新会导致页面报错的假象，误以为是后端代码出了问题。

6.2 答辩演示链路的编排：从需求到细节的讲述顺序

答辩时最忌一上来就打开系统点来点去。我习惯的讲述顺序分四步。第一步花一分钟讲背景，也就是第 1 章里提到的工单管理混乱现象，说清楚系统解决什么问题。第二步讲架构，画一下前后端分离的结构和五张核心数据表的关系，用数据库表结构截图说明状态机设计。第三步进入系统演示，按第 6.1 节的流程走一遍完整链路，过程中停下来讲关键点：创建工单时优先级字段的设计、分派时的权限校验、状态流转日志的生成、统计图表的 SQL 语句。第四步展示一段核心代码，比如状态机工具类或者乐观锁更新 SQL，边讲边改其中一部分，演示“如果我把它去掉，系统会出什么问题”。

6.3 老师最常问的三个问题及回答思路

第一个问题是“这个系统哪里体现了 MVC 架构”。回答时不要背定义，而是指着具体代码说：JSP 或 Vue 页面是 View，Controller 是接收参数的入口，Service 是 Model 层面的业务逻辑，MyBatis 的 Mapper 是数据访问层。第二个问题是“数据库为什么这么设计”。回答思路是倒着讲：先讲工单需要记录完整生命周期，所以要有状态日志表；又因为用户有多种角色，所以要拆出角色表和关联表；统计报表需要按状态聚合，所以 status 字段用 int 存状态码。第三个问题是“项目还有什么可以改进的地方”。这里千万不要说“没有”，通常会回答两点：引入 Redis 做会话共享以支持多节点部署，以及把 Spring 的 XML 配置迁移到注解和 JavaConfig。承认不足但给出明确改进方向，比自吹自擂更有说服力。

6.4 从交付到维护的一个习惯

这套项目交付之后回头看，我发现最值得的不是某个功能写得多漂亮，而是状态机、统一返回体、异常处理这些设计习惯。从那以后我每次接到带流程状态的项目，都强制先画一张状态流转表再写代码，把所有合法路径和不合法路径列全，再开始动 Mapper。这个习惯帮我在后面几个项目里少加了不少班。希望这份方案能帮你把工单系统这个课题做得顺利，不管是交作业还是真正投入使用，都能少走一些弯路。

本文还有配套的精品资源，点击获取