SpringBoot维修工单系统实战：从ZIP到上线全流程解析
简介：这是一套面向计算机专业本科生及Java全栈初学者的毕业设计/课程设计实战项目，聚焦维修服务场景下的工单全流程数字化管理。系统采用SpringBoot+Vue.js前后端分离架构，完整覆盖工单创建、智能分配、状态跟踪、权限管控、数据统计等核心业务，兼顾工程规范性与教学实用性。压缩包共55个文件，含33个Java后端逻辑类、11个Vue组件HTML页面、4个配置properties文件、2个XML配置及README.md、mvnw构建脚本等，总大小仅50KB，结构精炼便于快速部署与二次开发。已有59人学习下载，资源附带清晰的项目说明与启动指南，提供可直接运行的最小可行系统，包含数据库配置模板、Git版本管理规范及典型RESTful接口实现，是掌握SpringBoot自动配置、Vue组件通信与前后端联调的优质实践样本。
维修工单系统项目实战：从一份ZIP到能上线跑的完整思路
先泼一盆冷水：如果你手上拿到的是一份名为“基于SpringBoot的维修工单系统.zip”的项目压缩包，大概率里面有源码、有数据库脚本、还有一篇写得像模像样的毕业论文。但你把它解压之后，能不能跑起来，跑起来之后能不能应付实际业务，那就是另一回事了。我在多个维修/售后类项目里做过工单系统的梳理和重构，今天不打算讲那种“从零手写全部代码”的教程，而是结合SpringBoot技术栈，把工单系统的设计主线和落地细节摊开来讲。
这篇内容适合谁？适合两类人：一类是拿这个题目做毕设或课程设计的学生，你需要知道哪些模块是必须有的，怎么把系统讲得完整、有深度；另一类是刚转岗到运维/售后/设备管理方向的后端开发，你需要知道业务上要解决什么问题，而不是只对着CRUD写接口。无论你是哪一类，看完之后至少能做到：拿到一个新工单需求时，脑子里能快速形成表结构、状态机、权限模型和部署方案，而不是一上来就建一张“万能工单表”。
1. 维修工单系统的业务闭环：先搞清楚你的系统在管什么
1.1 工单不是“一个表”，是一条完整的问题处理链路
很多人做维修工单系统时，第一反应是建一张repair_order表，把报修人、故障描述、维修人、状态字段填进去，然后写几个增删改查接口，觉得就完事了。这是最大的误区。
工单系统的本质，是一个组织处理“异常事件”的流程管理工具。它要回答的问题不是“谁来修”，而是：问题怎么提出来的、派给了谁、处理到哪一步、有没有超时、用什么配件、花了多少钱、客户满不满意。这一整条链路才是工单系统的灵魂。
所以我在做需求分析时，一定会把工单拆成几个核心环节：报修/创建、受理/分派、处理/反馈、验收/关闭、回访/归档。每个环节都有自己的角色、对象和操作记录。比如创建时，普通用户看到的是“我提交了一个故障”，但系统内部需要记录设备编号、故障类型、紧急程度、故障截图、位置信息；派单时，班组长看到的是“待分派工单列表”，但系统底层要根据维修人员排班、技能标签、当前负载做分配决策；维修结束时，维修工提交的不是一句“修好了”，而是处理方式、更换配件、工时、剩余问题。
一个典型的闭环流程是这样走的：
- 报修人通过小程序、APP、Web端或扫码提交故障信息；
- 系统根据故障类型和区域自动生成一张工单，状态为“待分派”；
- 调度员/班长将工单指派给某个维修人员，状态变更为“处理中”；
- 维修人员接单、到场、维修、提交处理结果（含物料/工时）；
- 报修人或调度员验收确认，状态变更为“已关闭”；
- 系统生成满意度评价入口和维修记录台账。
上面这个闭环里，每一步都对应着独立的功能模块：工单管理、分派管理、处理反馈、物料管理、验收评价、统计报表。你把这个链路理顺了，页面、接口、表结构自然就出来了。
1.2 角色权限模型：工单系统里最重要的边界划分
工单系统的角色划分，直接决定系统架构的复杂度。我见过不少项目只在用户表里加一个role字段，取值是“管理员”和“普通用户”，然后管理员可以看到所有工单，普通用户看到自己提交的工单。这在演示系统里没问题，但一到真实场景就会被吐槽：维修工看不到待办怎么办？班组长看不到自己辖区内所有工单怎么办？财务要看物料成本，客服要看客户回访记录，这些怎么处理？
我的建议是，至少划分五类角色：
- 报修人（用户端）：创建工单、查看自己工单的处理进度、确认完成、评价；
- 调度员（分派端）：查看待分派工单、指派维修工、监督超时工单；
- 维修工（执行端）：查看分派给自己的工单、更新处理进度、提交处理结果和物料清单；
- 管理员（管理端）：用户管理、设备管理、工单全局查看、数据统计、系统配置；
- 财务/客服（协作端）：查看物料和费用数据、进行回访评价、导出报表。
SpringBoot生态里做权限控制，最常见的方案是Spring Security + JWT。你要注意的不仅是“能不能访问这个接口”，还要处理“他能看哪些数据”。这就涉及到数据权限的概念：维修工只能查assignee_id = 当前用户的工单，调度员只能查region_id = 自己管辖区域的工单，管理员不做限制。数据权限的过滤，我一般建议放在Service层做统一处理，而不是在每个Mapper查询里都手写条件，否则后续维护会非常痛苦。
1.3 SpringBoot在这个项目里具体承担了什么
既然标题是“基于SpringBoot”，那就要说清楚SpringBoot在工单系统里的技术定位。它不是一个“只能拿来跑CRUD”的框架，整个工单系统的技术分工大概是这样的：
- Spring MVC：提供RESTful接口，承接前端（Vue/小程序）发来的请求；
- Spring Validation + 统一异常处理：对入参做校验，对业务异常做全局兜底；
- Spring Task / Quartz：处理工单超时自动提醒、定时统计报表等；
- Spring Data Redis / Redisson：做高频数据缓存、分布式锁（比如防止重复派单）；
- Spring事务管理：保证工单派发、物料扣减、日志记录的一致性；
- MyBatis / MyBatis-Plus：操作数据库，我用MyBatis-Plus多一些，因为工单这类项目有大量条件分页查询，内置的
QueryWrapper和分页插件能省下不少时间。
需要特别提醒的是，SpringBoot的版本选择不是越新越好。很多同学拿到的项目是SpringBoot 2.7.x，配的是JDK 8，跑起来一点问题没有；但如果你把它强行升级到SpringBoot 3.x，JDK版本就得跟着升到17，一些老的第三方依赖（比如某些验证码组件、文件处理库）可能会出现兼容性问题。没有很强的理由，不要动版本。
2. 数据模型设计：工单系统的地基不能马虎
2.1 核心表结构：工单主表、状态流转记录表和物料明细表
工单系统的数据库设计，比大多数“学生管理系统”要稍微复杂些，但也没必要一上来就整那些花哨的微服务。单体应用、单库多表就完全够用。
我建议的核心表有这几张：
| 表名 | 用途 | 关键字段示例 |
|---|---|---|
user | 用户表 | id, username, password, real_name, phone, role_id, region_id |
device | 设备表 | id, device_no, device_name, location, purchase_date, status |
repair_order | 工单主表 | id, order_no, title, description, device_id, reporter_id, assignee_id, status, priority, create_time, finish_time |
order_flow | 工单流转记录表 | id, order_id, from_status, to_status, operator_id, remark, create_time |
order_material | 工单物料明细表 | id, order_id, material_name, material_code, quantity, unit_price |
order_evaluation | 评价表 | id, order_id, user_id, score, content, create_time |
message | 通知消息表 | id, user_id, order_id, content, is_read, create_time |
region | 区域表 | id, region_name, parent_id |
工单主表里我特别说下order_no。我见过有人直接用自增主键当工单号给客户看，结果客户反馈“你们是不是一个月才接了十几单？”，因为单号是连续的，暴露了业务量。规范做法是生成唯一业务单号，比如WO + 年月日 + 当日序号，或者用雪花算法生成纯数字ID再转字符串展示。这样既美观，又不会把系统内部的自增ID暴露给前端。
还有一个经常被忽略的字段：finish_time。这个字段在统计超时率、平均处理时长时非常重要。我发现很多项目只在主表里维护create_time和update_time，等写超时报表的时候发现没有“实际完成时间”这个数据，只能拿update_time凑数，但update_time可能会因为修改备注、补充附件而变化，统计出来完全不准确。
2.2 状态机设计：工单状态字段不适合用int瞎存
工单状态是工单系统里最容易设计烂的地方。常见的做法是直接在repair_order表里放一个status字段，然后代码里用if (status == 1)去判断。前端下拉框里写死“1待分派 2处理中 3已完成”。这样做在原型阶段没问题，但当流程调整时，比如要在“处理中”和“已完成”之间插入一个“待验收”状态，你就要把所有相关的前端页面、后端判断逻辑全都翻一遍。
更稳的做法是引入状态机模型。SpringBoot项目里可以逐层实现：最简单的是用枚举定义状态和允许的转换关系，复杂一点可以用Spring StateMachine框架做可视化配置。我推荐一个折中方案：用枚举定义状态流转表，并在Service层统一封装一个transition(orderId, targetStatus, operatorId)方法。这个方法内部先查当前状态，再判断目标状态是否在合法流转路径里，合法才更新，同时往order_flow表里插入一条流转记录。
工单的典型状态流转可以设计成这样：
| 当前状态 | 可流转到 | 触发动作 | 相关角色 |
|---|---|---|---|
| 待分派 | 处理中、已取消 | 分派/报修人取消 | 调度员、报修人 |
| 处理中 | 待验收、挂起 | 维修工提交完工 | 维修工 |
| 待验收 | 已完成、处理中 | 验收通过/不通过 | 报修人、调度员 |
| 挂起 | 处理中、已取消 | 重新处理/取消 | 调度员 |
| 已完成 | 已完成(不可改)、重新打开 | 回访后归档 / 客户反馈问题复发 | 客服、管理员 |
| 已取消 | 终态 | - | - |
有了这张表，你在写代码的时候，逻辑就非常清晰了。每个状态转换还可以配置“转换前的检查”和“转换后的动作”。比如：从“待分派”到“处理中”，转换前要检查维修工是否已接单；转换后要发送一条通知给报修人，告诉他已有人接单。这些都是状态机带来的好处。
2.3 唯一约束与索引：别等上线之后再来补
工单系统的查询场景非常多，而且基本都是以列表为主。你有没有想过，为什么工单列表页每次查询都很慢？多半是索引没建好。
我的索引设计习惯是这样的：
repair_order表：强制唯一索引uk_order_no；普通索引idx_assignee_status，覆盖“待办列表查询”（按维修工ID + 状态查）；联合索引idx_priority_create，用于“按优先级排序并分页”场景；order_flow表：普通索引idx_order_id，查询某张工单的流转履历；order_material表：普通索引idx_order_id，查询维修用了哪些物料；message表：联合索引idx_user_read，查“某个用户的未读消息”。
除了索引之外，status、priority这类字段一定要用int或tinyint，不要用字符串。虽然varchar看起来更直观（比如存'PENDING'），但存储空间更大、比较速度更慢，而且索引效率也会受影响。代码里用枚举类做映射就行，前端显示用字典翻译。
3. 工单接口与权限控制：写接口之前先把数据权限想清楚
3.1 RESTful接口设计：列表分页是多条件查询的重头戏
SpringBoot写接口本身不复杂，但工单系统的接口设计和普通CRUD不太一样，它大部分接口都是“带条件的列表查询”。如果你每个列表都写一个独立的Mapper方法，那SQL数量会爆炸。我建议统一封装一个PageResult<T>响应结构，配合MyBatis-Plus的Page对象和QueryWrapper，把条件查询收敛到一个通用入口。
举个典型接口对照：
| 接口 | 方法 | 说明 |
|---|---|---|
/api/orders | GET | 分页查询工单（条件：状态、设备、日期、优先级、报修人） |
/api/orders/{id} | GET | 工单详情（含流转记录、物料明细、附件列表） |
/api/orders | POST | 创建工单（报修人提交） |
/api/orders/{id}/assign | PUT | 指派工单（调度员操作） |
/api/orders/{id}/process | PUT | 处理工单（维修工更新状态、补充处理结果） |
/api/orders/{id}/accept | PUT | 验收工单（报修人/调度员确认） |
/api/orders/{id}/cancel | PUT | 取消工单 |
这里面有一个特别容易踩的坑：创建工单用的是POST，但分派工单为什么要用PUT？因为PUT语义上表示“更新整个资源”，分派操作本质上是在更新工单的assignee_id和status，用PUT是符合REST规范的。有些团队统一用POST加自定义操作路径，也可以，只要前后端约定一致就行。
3.2 防越权判断：不要只做接口登录校验
讲一个我在代码审计时经常发现的问题：很多系统确实在Controller层加了登录校验（@RequiresAuthentication之类），但完全没做数据权限判断。普通用户知道接口路径后，直接把/api/orders/123改成/api/orders/124，就能看到不属于自己的工单信息。
正确的做法是：在Service层，每个查询工单详情的接口都要先做归属判断。判断逻辑根据角色走不同分支：如果是维修工，只能查询assignee_id == currentUserId的工单；如果是报修人，只能查询reporter_id == currentUserId的工单；如果是调度员/管理员，才允许跨用户查询。这层逻辑一定要写在Service层，而不是Controller层，因为Controller层只负责HTTP协议层的拦截，Service层才是业务规则的最终执行地。
3.3 基于JWT的登录态与接口鉴权
工单系统一般都会做成前后端分离，所以SpringBoot后端的登录认证我习惯用JWT + Spring Security。整体思路是：
- 用户登录后，后端校验用户名密码，生成JWT Token（里面带上userId、roleId、regionId）；
- 前端把Token存在本地，每次请求在Header里加
Authorization: Bearer <token>； - 后端加一个OncePerRequestFilter，解析Token，验证签名和有效期，把用户信息放进ThreadLocal或SecurityContext；
- Security配置里对不同URL规则做权限匹配，比如
/api/admin/**需要ROLE_ADMIN，/api/orders/**需要任意登录用户。
这里建议Token的有效期不要设太长，我一般设2小时，再配合一个Redis刷新机制。工单系统里维修工和调度员往往是长时间挂着页面的，Token过期直接弹登录框会很烦。可以设计一个“续签过滤器”：请求过来时，如果Token剩余有效时间小于30分钟，就自动发一个新Token放在响应头里，前端拦截器收到后自动更新本地Token。这样用户全程无感。
4. 核心功能落地细节：这些模块最容易“看起来简单，做起来翻车”
4.1 工单创建与自动分派：事务和“不超卖”的设计
工单创建场景里有几个坑：
第一个是附件上传。报修人提交故障信息时，往往要上传现场照片。这里要考虑到图片可能很大（手机拍出来的照片动不动5-10MB），如果直接把图片Base64编码后塞进JSON传给后端，接口性能和内存都会被拖垮。正确的做法是：前端先调一个文件上传接口，把文件传到服务器或对象存储，拿到文件的URL，创建工单时只需要提交URL字符串即可。
我在项目里常用本地存储或OSS存储，SpringBoot的上传路径要注意配置好静态资源映射。这里有个经验：不要把上传文件直接放在src/main/resources/static下，因为这样打Jar包后静态文件会被封进Jar包里，后续运维替换文件会非常痛苦。正确做法是在配置文件里指定一个外部磁盘路径，比如D:/upload/或/data/upload/，然后使用WebMvcConfigurer做/upload/**的虚拟路径映射。
第二个坑是自动分派的并发问题。如果你的系统支持“自动分派”功能（根据维修工的负载情况自动分配），那么要特别小心并发场景：两个工单同时到达，都去查询状态为“空闲”的维修工A，然后同时把工单Assign给A，导致A的待办列表一下子多出两单。这里我用的方案是Redis分布式锁，锁的key是assign:lock:{workerId}，获取到锁才能执行分派逻辑，分派完成后释放锁。没有Redis环境的话，也可以用数据库的SELECT ... FOR UPDATE做行锁，但要注意锁的粒度和事务边界，避免锁长时间占用。
第三个坑是消息通知的时机。创建工单成功后，系统要给调度员发通知；分派成功后，要给维修工和报修人发通知；维修完成后，要给报修人发验收通知。如果这些通知逻辑散落在各业务代码里，后面加一种通知渠道（比如企业微信机器人）就要到处改代码。我建议用SpringBoot的事件机制：业务代码只是applicationEventPublisher.publishEvent(new OrderCreatedEvent(order))，然后专门写监听器去处理通知逻辑。这样业务主流程和通知渠道就解耦了。这和SpringBoot热词里的“springboot事件机制,如何监听某个事件”是直接对应的，也是面试官很爱问的点。
4.2 工单超时提醒：基于Spring Task的定时任务设计
维修工单最怕的是超时无人处理。线下流程里，工单压在一个人的抽屉里好几天，电话都被打爆了还不知道问题在哪。线上系统必须要有超时提醒机制。
我的做法是设计一张remind_config表，里面配置“超过N小时未处理就提醒”。然后写一个Spring Task定时任务，每5分钟扫一次repair_order表，找出所有超过时限且状态还在“待分派”/“处理中”的工单，给对应的调度员和维修工发送站内信或者短信提醒。要注意的是，定时任务需要做好“幂等”：同一个提醒任务不能重复发送。我用的是order_flow表里加一个remind_count字段，每次发送提醒前先判断上次发送时间是否已超过提醒间隔，避免系统一重启就全员轰炸。
另外一个经验：定时任务不要写得太大、太复杂。我见过有人把“统计报表”和“超时提醒”放在同一个定时任务方法里，结果报表统计卡了一个小时，导致当天所有的超时提醒都延迟了。正确做法是拆成不同的Job，就算某个Job出了问题，也不影响其他定时任务。
4.3 文件下载与内容安全：工单附件不要直接用GET裸奔
热词里有几个关于“下载文本文档”“PDF XSS攻击”的搜索记录，我猜你处理工单附件时也遇到了文件安全的问题。这里要说说文件下载的经典坑。
工单附件上传后，最常见的下载方式是前端拼URL：<a href="/upload/xxx.pdf">下载</a>。这种GET直接下载的方式有几个问题：一是没法做权限校验，只要拿到URL，谁都能下载；二是文件名如果包含中文或特殊字符，容易导致下载乱码；三是如果文件内容里包含恶意脚本（比如PDF里嵌入JS），某些浏览器可能会触发XSS，尤其当文件是HTML、SVG、Markdown这类可执行内容时，Servlet容器可能直接把内容按HTML解析，造成存储型XSS。
安全做法是：文件下载走一个后端接口，比如GET /api/files/{fileId}/download。接口内部先校验当前用户是否有权限访问这个工单，再校验文件类型，最后通过ResponseEntity返回文件流，并强制设置Content-Disposition: attachment; filename*="UTF-8''文件名"。同时，对于上传的附件类型，要在上传时做白名单过滤，禁止上传html、svg、js等高风险后缀，建议把PDF文件的下载响应头加上X-Content-Type-Options: nosniff，防止MIME嗅探。这些不是教科书里的“理论安全”，是真实发生过的问题。
5. 部署落地与信创环境适配：从开发机到服务器的最后一公里
5.1 打包运行：Jar包方式与外部配置文件
很多同学在开发环境跑SpringBoot项目很顺利，一部署到服务器就各种“页面打不开”“数据库连不上”，问题大多出在配置上。
开发环境下，application.yml里往往写的都是localhost链接数据库、Redis没密码。到了部署环境，这些都要改成服务器实际的IP、端口和账号密码。如果每次部署都去改代码里的配置再打包，那运维会疯掉的。我的习惯是：配置文件外置。打包时排除application.yml，然后在Jar包同目录下放一个config/application.yml，SpringBoot会自动加载外部的config目录下的配置，且优先级高于Jar包内的配置。这样部署时只需要改配置文件，不用重新打Jar包。
另外，Jar包部署时要注意内存参数。我曾经在服务器上直接用java -jar app.jar启动工单系统，结果运行几天后频繁卡死，一看内存监视器，堆内存一直在高位，GC日志刷屏。默认的-Xmx是物理内存的1/4，如果服务器只有2G内存，JVM最多用512M，对于工单系统这类有列表缓存、文件流的应用来说很容易触发频繁FullGC。我的启动参数是：
-Xms512m -Xmx1024m -XX:+UseG1GC -Dfile.encoding=UTF-8如果你的服务器内存较大（比如4G以上），可以适当调大堆内存，但也不要超过物理内存的一半，要给操作系统和数据库留余地。
5.2 容器化部署：Docker + Compose 一键拉起依赖
工单系统最舒服的部署方式，我推荐Docker Compose。因为系统依赖MySQL、Redis，如果全手工装一遍，至少要半小时，还容易装错版本。用Compose把MySQL、Redis、后端应用三个容器编排在一起，一条docker compose up -d命令就能全部启动。
写一个最小可用的Dockerfile示例：
FROM openjdk:8u212-jre-alpine ENV TZ=Asia/Shanghai WORKDIR /app EXPOSE 8080 ADD target/repair-order-system.jar /app/repair-order-system.jar ENTRYPOINT ["java","-jar","repair-order-system.jar"]注意时区设置。很多工单系统部署后，发现系统时间和实际时间差8个小时，就是因为容器默认时区是UTC。加一行ENV TZ=Asia/Shanghai，或者在application.yml里配置spring.jackson.time-zone: GMT+8和JDBC的连接参数serverTimezone=Asia/Shanghai，能省下一堆时间性问题。
Compose文件里，MySQL容器要挂载数据卷，否则容器一删，工单数据全没了。Redis也同理，把data和dump.rdb挂出来。
5.3 信创环境下的适配：东方通TongWeb和国产数据库替换
这是从热词里发现的很多人在搜的话题：“改成信创的话,是否需要东方通的tongweb”。我专门把这节拿出来说。信创环境下的中间件替换，通常涉及三个层面的适配：应用服务器、数据库和操作系统。
首先是应用服务器。传统SpringBoot项目直接用内置Tomcat跑，打成Jar包或者War包都行。但如果要求部署到东方通TongWeb等国产应用服务器，需要注意几点：
- 打包方式要改为War包，并且
pom.xml里把spring-boot-starter-tomcat的<scope>provided</scope>排除掉； - 项目里如果使用了
@ServletComponentScan、WebFilter等Servlet原生组件，TongWeb对Servlet API的兼容性通常没问题，但不同版本之间可能有差异，建议先做快速冒烟测试； - 文件上传路径、日志输出路径等在TongWeb里的相对路径规则和Tomcat不同，要全部改为绝对路径；
- 如果用到了
javax.servlet包，注意TongWeb的类加载机制，尽量使用中间件自带的Servlet API，避免版本冲突。
其次是数据库。工单系统如果迁移到达梦（DM）这类国产数据库，SQL方言要做调整。最典型的是分页：MySQL用LIMIT offset, size，达梦支持Oracle风格的分页写法ROWNUM或达梦自己的分页语法。如果你用MyBatis-Plus的分页插件，一般可以通过配置数据库类型来适配。但如果你手写了大量原生SQL，那么迁移时排查SQL兼容性问题会比较耗时。建议在项目早期就尽量使用MyBatis-Plus提供的QueryWrapper和LambdaQueryWrapper，少写复杂多表SQL，这样数据库切换时的改动量会小很多。
最后是操作系统。如果部署到麒麟等国产操作系统上，最需要注意的是JDK的安装方式和字符集。建议提前确认JDK位数和版本（一般是ARM或x86架构），同时启动脚本里指定-Dfile.encoding=UTF-8，否则日志里的中文会乱码。
这里再补充一句：不是所有项目都强制要求替换到TongWeb。如果你的项目只是部署在信创机器上，但允许保留OpenJDK，那SpringBoot的内置Tomcat通常也能直接用。具体是否替换，取决于项目交付要求。不要盲目为了“信创”两个字把技术栈推倒重来，先确认需求边界。
6. 线上问题排查实录：那些工单系统特有的“隐藏雷区”
6.1 时间字段的时区陷阱
工单系统对时间特别敏感：“提交时间”“派单时间”“完成时间”“超时时间”全都要拿来算时效。我遇到过一个经典bug：数据库里存的工单创建时间比实际时间早了8小时，原因是JDBC连接串里的serverTimezone=UTC。这个字段如果只是展示还好，但当你用SQL做超时判断时（WHERE create_time < NOW() - INTERVAL 2 HOUR），时间差直接导致判断错误，明明没超时的工单被系统判定超时，然后给所有维修工发了超时提醒短信。
排查思路：先看数据库时间（SELECT NOW()），再看应用日志时间，最后看前端展示时间。三者的时区是否一致，是排雷的关键。规范做法是：数据库连接串里明确写上serverTimezone=Asia/Shanghai，JVM参数加-Duser.timezone=GMT+8，SpringBoot的Jackson配置设好spring.jackson.date-format和time-zone，三层统一，基本就稳了。
6.2 “待办列表”越来越慢：分页查询的性能瓶颈
工单系统上线三个月后，维修工反映“待办列表越翻越慢”，尤其是那种老维修工，名下积累了几百条已处理工单，每次列表查询要好几秒。我排查分页查询后发现问题出在深分页上。
MySQL的LIMIT 10000, 10并不是跳过前面10000条再取10条那么简单，数据库还是要扫描前面10000条记录再丢弃，数据量一上来，性能就急剧下降。优化方案有两个：一是给列表查询加上“按时间范围、状态”等强过滤条件，减少扫描行数；二是采用“游标分页”，即不传pageNum，而是传lastId（上一页最后一条记录的ID），用WHERE id > lastId ORDER BY id LIMIT 10来查询下一页。
具体到工单查询，按create_time排序的话，可以在联合索引上再加create_time字段，让排序走索引，而不是等到查出来再排序。
6.3 状态并发更新：一张工单被两个人同时处理
工单在“待分派”状态时，调度员A和调度员B同时打开了工单列表，都看到这张单子待分派，于是A分派给了维修工X，B分派给了维修工Y。这会导致一个后果：工单先被A更新成“处理中”，X开始处理；随后B的接口也执行成功，把assignee_id改成Y，status还是“处理中”。X白干一场，Y收到一条和自己没关系的新待办。
处理方案是在更新工单时，SQL语句里加上状态条件：UPDATE repair_order SET assignee_id=#{newWorkerId}, status=2 WHERE id=#{orderId} AND status=1。如果更新影响行数为0，说明工单状态已经被别人改过了，当前操作直接抛业务异常“工单已被处理，请刷新页面”。这种方式比分布式锁更轻量，也足够应对绝大多数工单更新场景。
7. 给工程师的几点实用建议
7.1 写清楚“操作日志”，不要只留一张业务表
工单系统有很强的审计需求——哪个工单、什么时间、被谁从什么状态改到了什么状态、改了什么字段，这些全都要留痕。很多人只记了order_flow表，但order_flow只负责状态流转，如果维修工只改了“处理结果描述”而没改状态，操作痕迹就丢了。我建议再增加一张通用操作日志表，用AOP切面的方式统一记录Controller层的修改操作，把请求路径、参数、操作人、时间全部记录下来。这样出问题后可以从头回溯，这在排查纠纷时特别重要。
7.2 先用“假数据”把前端全部跑通，再回头调后端
工单系统最耗时间的往往不是后端接口逻辑，而是前后端联调。我有一次做维修工单管理页，后端状态字段改了好几次，结果前端每个页面的状态标签都得跟着改，非常痛苦。后来我跟前端同事约定：前端页面里所有状态、角色、优先级的展示，一律走后端提供的字典接口，前端不做硬编码。这样后端调整状态枚举后，前端只需要重新拉一次字典就自动更新了，联调效率提升了不止一半。
7.3 技术栈“够用就好”，不要把简单系统做成微服务
最后聊点踩坑经历。工单系统本质上是典型的中小型业务管理系统，单体架构完全够用，没必要为了简历上多个“微服务”字样就把系统拆成订单服务、用户服务、通知服务三个独立进程。微服务带来的分布式事务、接口调用链监控、服务注册发现，对一个业务量不大的工单系统来说是纯粹的负担。我见过团队拿一个几十人的内部维修工单系统硬套Spring Cloud，最后维护成本比开发成本还高。如果真需要扩展，也建议先做模块化单体，模块边界清晰，后续按需拆分，远比一开始就搞分布式稳妥得多。
这个项目本身并不难，难的是把流程理清楚、把状态管好、把权限守住。照着上面的思路把表结构、状态机、接口和部署方案定下来，再动手写代码，你会发现整个开发过程顺畅很多。
本文还有配套的精品资源，点击获取