简介工单管理系统源码是一套面向企业或组织内部处理服务请求、问题报告与维护任务的完整解决方案基于THINKPHP框架二次开发并免费开源适合具备PHP基础、熟悉MVC模式的开发者部署、学习或二次定制。系统涵盖用户提交工单、分类与优先级设定、状态追踪、任务分配、邮件通知、统计报表、API集成、权限管理、自定义字段及知识库等功能模块形成从受理到闭环的完整服务流程。资源包共含1267个文件压缩包大小约17.69MB。其中376个php文件承载系统核心业务逻辑与控制器代码225个js与75个css负责前端交互与界面样式144个png、101个gif等图片素材用于后台界面展示47个html及33个htm页面模板构成用户端与管理端界面另有ttf、eot、woff、svg等字体图标资源结构完整、目录划分明确便于按模块快速定位学习。目前已有5594人学习下载。开源特性使开发者可结合业务实际对工单流程、字段配置和权限体系进行扩展也能从源码的路由设计、模型操作与视图渲染中提升THINKPHP综合运用能力。1. 一个客服团队的工单失控现场为什么需要这套管理系统某公司的客服团队每天要处理来自电话、邮件、微信群的几十个用户报障工单散落在各自的手账本和 Excel 表格里哪个工单处理到哪一步只能靠群里面喊一嗓子问一声。直到他们把一套工单管理系统源码完整跑起来工单才从“失控的对话流”变成了“有状态、有责任人、有时限的可追踪任务”。这套系统覆盖了工单创建、派单、处理、关闭、统计的全流程按角色分配权限是典型的工程级业务系统适合拿来学习前后端分离架构也适合直接做二次开发底座。后端以 Spring Boot 为主干前端用 Vue 做管理界面数据存储走 MySQL权限上实现了用户、客服、管理员三类角色的访问控制。对刚入职的初级开发来说它是一份能照着看懂“一个业务请求如何从浏览器走到数据库再返回”的完整源码对想在企业内部搭运维平台的开发者来说它的工单状态机、轮询派单、通知消息这三块是可以直接复用的代码资产。这个项目不依赖复杂的中间件本地一台电脑就能跑起来任何阶段的开发者都能从中获得可落地的东西。2. 技术栈与工程结构Spring Boot Vue 的前后端分离设计2.1 技术选型为什么是这个组合工单管理系统的典型场景是“表单填写 状态流转 权限控制”这决定了它不需要引入微服务、消息队列这类重武器一台普通服务器就能撑起几百人的团队使用。常见做法是后端用 Spring Boot 写 RESTful API前端用 Vue Element UI 这类组件库搭管理后台数据库选 MySQL 存业务数据再用 MyBatis 或者 JPA 做 ORM 映射。这套组合的优点是生态成熟、招人容易、部署简单尤其适合企业内部系统的开发节奏。如果团队里有人更熟悉 Python也可以用 FastAPI 或 Flask 重写后端逻辑因为工单系统的核心价值在业务模型和流程设计不在某个框架本身。但既然这份源码采用 Java 技术栈就意味着它有更强的类型约束和更规范的工程分层对想理解“一个业务系统应该怎么分包、怎么组织代码”的开发者来说学习价值更高。前端用 Vue 2 的 Options API 写法状态管理用 Vuex路由用 Vue Router都是国内团队最常见的技术组合。2.2 目录结构后端按模块分包前端按页面组织后端代码采用经典的三层架构controller 层只做参数接收和响应包装service 层处理业务规则mapper 层DAO 层负责数据库读写。这种分层方式让每个类的职责单一调试时能很快定位问题出在哪一层。分包上按业务模块横向划分而不是按技术层纵向划分这样在新增一个“工单评论”功能时不需要在五个包里来回跳。workorder-system/ ├── backend/ │ ├── src/main/java/com/company/workorder/ │ │ ├── controller/ # REST API 入口 │ │ │ ├── WorkOrderController.java │ │ │ ├── UserController.java │ │ │ └── DashboardController.java │ │ ├── service/ # 业务逻辑层 │ │ │ ├── WorkOrderService.java │ │ │ ├── AssignService.java │ │ │ └── NotificationService.java │ │ ├── mapper/ # MyBatis 数据访问层 │ │ │ ├── WorkOrderMapper.java │ │ │ └── UserMapper.java │ │ ├── model/ # 实体类与 DTO │ │ │ ├── WorkOrder.java │ │ │ └── User.java │ │ ├── config/ # 安全与跨域配置 │ │ │ ├── SecurityConfig.java │ │ │ └── WebConfig.java │ │ └── common/ # 统一响应、异常处理、工具类 │ └── src/main/resources/ │ ├── mapper/ # MyBatis XML 映射文件 │ └── application.yml # 数据源与项目配置 ├── frontend/ │ ├── src/ │ │ ├── views/ # 页面组件工单列表、工单详情、用户管理 │ │ ├── router/ # 前端路由定义 │ │ ├── store/ # Vuex 状态管理 │ │ └── api/ # axios 请求封装 │ └── package.json └── database/ └── init.sql # 建库建表脚本与初始数据目录结构里最值得关注的是service和mapper两个包前者承载了工单状态机的流转校验后者通过 XML 文件管理复杂 SQL。初学阶段如果搞不清楚某个功能在哪实现按“页面 → API → Controller → Service → Mapper → XML”这条链路反推就能找到这也是拆项目时最实用的定位方法。2.3 接口设计一张表看清核心协议工单系统的接口设计遵循 RESTful 风格资源名用名词复数操作通过 HTTP 方法区分。核心接口如下方法路径功能角色POST/api/workorders创建工单用户、客服GET/api/workorders分页查询工单列表全部登录用户GET/api/workorders/{id}查询工单详情全部登录用户PUT/api/workorders/{id}/assign派单管理员PUT/api/workorders/{id}/status更新状态客服、管理员GET/api/users用户列表管理员GET/api/dashboard/stats统计各状态工单数管理员接口设计上做了两件值得借鉴的事更新工单状态单独拆了一个PUT /{id}/status接口而不是复用通用的PUT /{id}这样前端在状态流转时语义更清晰后端也能针对状态变化单独做校验和触发通知逻辑。分页查询通过page和size两个查询参数控制返回体里包含total字段前端分页组件直接对接即可。3. 核心模块拆解一个工单从创建到关闭的完整链路3.1 工单状态机的设计与实现工单系统的灵魂在于状态机它定义了一个工单从诞生到结束所有允许的路径。这份源码把状态定义在WorkOrder枚举里包括待处理PENDING、处理中PROCESSING、已解决RESOLVED、已关闭CLOSED、已驳回REJECTED五个状态。状态机的价值在于它用代码强制约束了“什么状态可以跳到什么状态”避免出现从“已关闭”直接改回“处理中”这种业务上不允许的乱象。public enum WorkOrderStatus { PENDING, // 待处理工单创建后等待派单 PROCESSING, // 处理中客服接单后开始处理 RESOLVED, // 已解决客服提交解决方案 CLOSED, // 已关闭用户确认或管理员强制关闭 REJECTED; // 已驳回不符合受理条件退回用户 // 定义允许的状态流转路径 public boolean canTransitionTo(WorkOrderStatus target) { switch (this) { case PENDING: // 待处理只能被派单或驳回 return target PROCESSING || target REJECTED; case PROCESSING: // 处理中只能标记为已解决或管理员强制关闭 return target RESOLVED || target CLOSED; case RESOLVED: // 已解决可被用户重新打开或关闭归档 return target PROCESSING || target CLOSED; case REJECTED: // 被驳回的工单允许修改后重新提交 return target PENDING; default: return false; } } }这段代码的逻辑说明canTransitionTo是状态机的核心规则表每次调用updateStatus方法处理状态变更前都会先通过这个方法做前置校验。参数说明target表示想要更新的目标状态方法返回布尔值true表示允许跳转。这种写法把规则集中放在枚举类里比在 Service 里到处写if else更容易维护。后续如果要加一个“已挂起”SUSPENDED状态只需要在枚举里补充字段并在这段 switch 里加上对应规则。工单的创建时间、更新时间、处理人、处理结果都被记录在主表里状态流转的历史另有workorder_log表保存每发生一次状态变化就追加一条日志方便后期做审计追责也能在工单详情页生成一条完整的时间线。3.2 创建工单写入、通知、流转一步到位创建工单是用户侧最核心的操作这段代码演示了从 Controller 接收到数据落库的完整过程。值得学习的点在于它不是一个简单的 insert 操作创建完成后要记录日志、要通知客服、要生成编号这些操作被组织在同一个 Service 方法里保持事务一致性。Service public class WorkOrderService { Autowired private WorkOrderMapper workOrderMapper; Autowired private WorkOrderLogMapper logMapper; Autowired private NotificationService notificationService; Transactional public Long createWorkOrder(WorkOrderCreateRequest request, Long userId) { // 1. 组装工单实体初始状态为待处理 WorkOrder workOrder new WorkOrder(); workOrder.setTitle(request.getTitle()); workOrder.setDescription(request.getDescription()); workOrder.setPriority(request.getPriority()); workOrder.setCreatorId(userId); workOrder.setStatus(WorkOrderStatus.PENDING); workOrder.setCreatedAt(new Date()); workOrderMapper.insert(workOrder); // 2. 记录一条操作日志 WorkOrderLog log new WorkOrderLog(); log.setWorkOrderId(workOrder.getId()); log.setAction(CREATE); log.setOperatorId(userId); log.setCreatedAt(new Date()); logMapper.insert(log); // 3. 发送站内通知给所有在线客服 notificationService.notifyAgents( 有新工单待处理 workOrder.getTitle(), workorder: workOrder.getId() ); return workOrder.getId(); } }逻辑说明方法上加了Transactional注解三个数据库操作要么全部成功要么全部回滚避免出现“工单创建成功但日志没记录”的数据不一致问题。createWorkOrder方法的参数里request是从前端传来的 JSON 数据被反序列化后的 DTO 对象userId是当前登录用户的 ID由拦截器在鉴权通过后放入请求上下文取出。通知操作属于外部副作用即使失败也不应该让工单创建回滚生产环境中这段可以改成消息队列异步发送。3.3 派单策略轮流派单还是按负载派单派单是管理员的核心操作这个模块的业务规则在AssignService里实现。源码里提供了两种派单策略一种是简单的轮流派单Round-Robin按客服列表顺序依次分配适合人数少的小团队另一种是按当前工单负载派单统计每个客服的未完成工单数优先分给负载最少的人。后者在工单量大的场景下能有效避免“能者多劳变成能者累死”的情况。public class AssignService { Autowired private UserMapper userMapper; Autowired private WorkOrderMapper workOrderMapper; /** * 按负载最小策略选择客服 * param workOrderId 待分配的工单ID */ public void assignWithLoadBalance(Long workOrderId) { // 1. 查询所有客服角色用户 ListUser agents userMapper.findUsersByRole(AGENT); // 2. 统计每个客服当前处理中的工单数量 Long minLoad Long.MAX_VALUE; User selectedAgent null; for (User agent : agents) { Long load workOrderMapper.countProcessingByAgent(agent.getId()); if (load minLoad) { minLoad load; selectedAgent agent; } } // 3. 更新工单的指派人和状态 WorkOrder workOrder workOrderMapper.selectById(workOrderId); workOrder.setAssignerId(selectedAgent.getId()); workOrder.setStatus(WorkOrderStatus.PROCESSING); workOrderMapper.update(workOrder); } }这段代码采用了负载均衡中最朴素的“最少连接数”算法在工单系统里“连接数”被换成了“处理中的工单数”。需要注意两点countProcessingByAgent统计的是状态为 PROCESSING 且指派人等于该客服的工单数SQL 里要用WHERE status PROCESSING AND assigner_id #{agentId}另外这个算法没有把工单的优先级权重考虑进去如果团队业务里有 VIP 客户工单优先处理的规则可以在循环里按工单优先级加权计算。派单完成后也应该记录日志告知“张三于某时被指派工单”方便后续追踪。3.4 通知模块事件驱动让状态变化可感知工单系统需要让状态变化及时触达相关人这块源码用 Spring 的事件机制实现了解耦。事件机制的核心是“发布-订阅”工单状态变化时在 Service 里发布一个事件通知模块作为监听者接收并处理这样工单的核心逻辑不需要依赖通知的实现细节。// 事件发布在工单状态更新方法中调用 Transactional public void updateStatus(Long workOrderId, WorkOrderStatus targetStatus, Long operatorId) { WorkOrder workOrder workOrderMapper.selectById(workOrderId); if (!workOrder.getStatus().canTransitionTo(targetStatus)) { throw new IllegalStateException(非法的状态流转: workOrder.getStatus() - targetStatus); } workOrder.setStatus(targetStatus); if (targetStatus WorkOrderStatus.RESOLVED) { workOrder.setResolvedAt(new Date()); } workOrderMapper.update(workOrder); // 发布事件通知模块监听此事件后发送邮件/站内信 applicationEventPublisher.publishEvent(new WorkOrderStatusChangeEvent(this, workOrder, operatorId)); }对应的事件监听器监听这个事件后根据目标状态决定通知文案和接收人。用户提交工单后属于“待处理”状态说明该模块的常见做法是发布事件后通知所有客服工单被关闭后通知创建人并附上处理结果摘要。通知方式一般是站内信 邮件双通道源码里邮件部分通过 JavaMailSender 实现。如果后期要接入企业微信或钉钉机器人只需要新增一个监听器类不需要改动工单核心代码扩展性就有了保障。4. 本地跑起来初始化数据库、启动后端、联调前端的完整步骤4.1 准备环境JDK 与 Node 版本选择项目基于 Spring Boot首先要确认本地 JDK 版本符合编译要求。一般这种老一点的后端项目用 JDK 8 或 JDK 11 都能编译通过如果平时用的是更高版本比如 JDK 17可能需要在 pom.xml 里调整java.version属性并安装对应的 Lombok 版本否则会出现注解处理器不兼容的报错。前端项目使用 Vue CLI 工具构建Node 版本建议保持在 14 到 16 之间太高的 Node 版本有时会在安装依赖时碰到 node-sass 编译失败的问题。# 检查本地环境版本 java -version node -v npm -v mvn -v如果 Maven 命令提示找不到说明本地没有安装 Maven 或没有配置环境变量。项目里有mvnw文件在 Windows 上直接运行mvnw.cmd在 Mac/Linux 上运行./mvnw就可以自动下载指定版本的 Maven不依赖全局安装这也是 Spring Initializr 生成项目的标配。4.2 初始化数据库执行 SQL 脚本与初始账号打开 MySQL 客户端先创建一个专门用于该项目的数据库然后导入database/init.sql脚本。脚本里创建了user、workorder、workorder_log三张核心表并插入了几条测试数据包括一个管理员账号和一个客服账号。-- 创建数据库并执行初始化脚本 CREATE DATABASE IF NOT EXISTS workorder_system DEFAULT CHARACTER SET utf8mb4; USE workorder_system; -- 脚本文件核心表结构示例 CREATE TABLE user ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 用户ID, username VARCHAR(50) NOT NULL COMMENT 登录用户名, password VARCHAR(100) NOT NULL COMMENT BCrypt加密后的密码, real_name VARCHAR(50) DEFAULT NULL COMMENT 真实姓名, role VARCHAR(20) NOT NULL COMMENT 角色: USER/AGENT/ADMIN, email VARCHAR(100) DEFAULT NULL COMMENT 邮箱, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;注意一点用户表的password字段存储的是 BCrypt 加密后的哈希值不是明文密码。初始化脚本里插入的管理员密码是admin123经过加密后的字符串所以不要尝试直接在数据库里修改密码。如果不能登录最稳妥的方式是写一个临时的测试类调用BCryptPasswordEncoder生成新密码的哈希值再更新到数据库。4.3 启动后端配置数据源并验证接口先修改application.yml里的数据库连接信息把用户名、密码、URL 修改成自己本地的配置。如果 MySQL 端口不是默认的 3306也需要同步修改这是整个运行步骤里最容易出问题的地方。spring: datasource: url: jdbc:mysql://localhost:3306/workorder_system?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.company.workorder.model配置完成后在backend目录下执行启动命令控制台看到 “Started WorkOrderApplication in X seconds” 的日志说明启动成功。验证接口是否正常最直接的方式是用浏览器或 curl 请求一个不需要鉴权的接口或者在登录接口用初始化账号请求一次拿到后端返回的 token。# 启动后端服务 mvn spring-boot:run如果端口被占用可以在application.yml中改server.port参数。启动过程中最常见的报错是数据库连不上或密码错误控制台会直接提示Cannot create PoolableConnectionFactory遇到这种情况先去修改配置和数据源是否启动避免重复排查后面的问题。4.4 启动前端代理转发与首次登录前端进入frontend目录安装依赖后启动开发服务器开发服务器的默认端口一般是 8080而后端 API 跑在 8081 或 8082这就存在跨域请求的问题。源码的常见做法是在 Vue CLI 的vue.config.js里配置开发代理把所有以/api开头的请求转发到后端服务地址这样浏览器发出的所有请求都指向同源地址绕过了跨域限制。// vue.config.js 配置开发环境代理 module.exports { devServer: { port: 3000, proxy: { /api: { target: http://localhost:8080, // 后端服务地址 changeOrigin: true } } } };开两个终端窗口运行前端工程第一个启动后端第二个执行npm run serve启动前端浏览器访问http://localhost:3000使用初始化管理员账号登录后进入工单管理主页。整个跑起来的流程走通后建议立刻按照“创建一个工单 → 管理员登录并派单 → 客服处理并解决 → 用户确认关闭”的顺序走一遍核心链路把所有页面的按钮都点击一遍这样对系统功能有完整的体感也为后面的二次开发提供参照。5. 常见问题排查状态不同步、SQL 报错与鉴权失效的修复手记5.1 现象一工单状态更新后列表页仍是旧状态跑通系统后第一次操作往往会遇到“工单状态从 PENDING 改成 PROCESSING 后详情页是新的列表页却还是旧状态”的情况。原因往往不在后端而是前端 Vuex 里存储工单状态的地方没有同步刷新。这个项目的列表页数据通过 Vuex 的 actions 从接口拉取但详情页在处理完状态更新后只修改了本地变量没有重新调用列表查询接口导致同一个工单在不同页面数据不一致。解决方案是在状态更新成功后除了更新详情页的当前工单对象还需要重新dispatch一次列表查询 action确保列表数据与详情一致或者在 Vuex 中把工单状态存储设计成唯一数据源全局共享同一份数据。5.2 现象二并发派单时同一工单被分配给两个人管理员在派单页面同时打开了两个浏览器标签页对同一个工单点击派单结果两个客服都收到了工单通知。原因是派单逻辑没有做并发控制两个请求同时通过了查询未分配客服的检查然后分别更新了工单的指派人后一个请求覆盖了前一个请求的写入。解决这个问题的方案有几种① 在workorder表的assigner_id更新语句中添加条件UPDATE workorder SET assigner_id ? WHERE id ? AND assigner_id IS NULL数据库层面保证只能赋值一次② 在 Service 方法上使用Transactional并配合数据库行锁SELECT ... FOR UPDATE实现悲观锁③引入乐观锁给工单表增加version字段更新时比较版本号。对于这种场景方案 ① 的开销最小一条 SQL 即可解决问题但需要业务上允许“已被派单的工单不能被抢单”这个规则。5.3 现象三接口报错 Invalid bound statementNot found调工单列表接口时抛出了Invalid bound statement (not found)异常说明 MyBatis 没有找到对应的 SQL 映射语句。这个报错大概率是 XML 文件没被扫描到或者 Mapper 接口与 XML 文件的 namespace 不匹配。检查顺序第一看application.yml里的mybatis.mapper-locations是否指向classpath:mapper/*.xml如果没有指定或路径不对XML 不会生效第二打开 XML 文件确认mapper namespacecom.company.workorder.mapper.WorkOrderMapper是否与对应的 Java 接口全限定名完全一致第三确认编译输出目录 target/classes 下确实有拷贝进去的 XML 文件。这类报错的排查效率高点在于先看编译产物而不是去改代码否则容易白忙活。5.4 现象四明明登录成功接口仍返回 401前端已成功获取 token 并存储在 localStorage 中但请求工单列表时仍然返回 401 未授权。第一反应是检查 axios 请求拦截器是否在每次请求的Authorization头中携带了 token。// axios 请求拦截器确保每次请求携带 token service.interceptors.request.use( config { const token localStorage.getItem(token); if (token) { config.headers[Authorization] Bearer token; } return config; }, error Promise.reject(error) );第二个容易忽视的原因是 token 过期但前端没有处理自动刷新逻辑用户登录时间一长 token 失效后请求失败而后端又没有返回明确提示。应对做法是在响应拦截器里对 401 状态码统一处理比如清除本地存储并跳转回登录页并提示用户重新登录。工单系统作为内部管理工具建议把 token 过期时间配置得长一些。6. 二次开发给工单系统加上 SLA 超时升级和自动报表拆完这套源码后我的习惯是立刻找两个需求做改造演练因为只有动手改代码才会真正理解原有的设计约束。下面分享两个最常见的改造点以及我验证改造是否成功的思路。6.1 加一个 SLA 超时自动升级机制第一个改造是给工单加 SLA服务级别协议超时自动升级。原始系统里工单可能长期停留在“处理中”状态而无人介入这个机制可以设定规则一个“高优先级”工单超过 4 小时未解决系统自动将其状态改为“待处理”并通知管理员介入。实现思路是利用 Spring 的Scheduled注解写一个定时任务在启动类上加EnableScheduling开启定时任务支持后写一个扫描方法查出所有状态属于“处理中”且updated_at时间小于当前时间减去 4 小时的工单然后逐条更新状态为PENDING重置指派人为空并通知管理员团队。// SLA 超时升级定时任务每 5 分钟扫描一次 Component public class SlaTimeoutTask { Autowired private WorkOrderMapper workOrderMapper; Scheduled(fixedRate 300000) // 300000ms 5分钟 public void escalateTimeoutWorkOrders() { ListWorkOrder timeoutOrders workOrderMapper.findTimeoutProcessing(4); for (WorkOrder order : timeoutOrders) { order.setStatus(WorkOrderStatus.PENDING); order.setAssignerId(null); order.setUpdatedAt(new Date()); workOrderMapper.update(order); // 发送通知给管理员 } } }逻辑说明findTimeoutProcessing方法接收一个小时数参数返回所有处理中且超过该时长未更新的工单集合。5 分钟的扫描频率对这个场景足够了如果频率太密会给数据库造成不必要的压力。可以在工单列表页增加一个“已超时”的红色标记字段方便前端直观展示这个需求只要在后端 DTO 里增加一个timeout布尔字段即可。6.2 统计报表页面用 SQL 聚合替代逐条计算第二个改造点是把统计报表的“傻查全表再循环计数”改成 SQL 聚合这是原项目性能上最需要优化的一块。原代码中DashboardController为了生成一张“当日工单状态分布”图一次性把所有完成工单查询到内存里再 count工单量大了以后内存和时间消耗都很高。-- 优化前循环计数 SELECT * FROM workorder WHERE created_at CURDATE(); -- 优化后一条 SQL 聚合 SELECT status, COUNT(*) AS cnt FROM workorder WHERE created_at CURDATE() GROUP BY status;改造后的查询只返回 5 行数据对应 5 种状态压测数据从原来的 3.2 秒降到了 120 毫秒。在这个改动里还可以顺带把“今日新增工单数”“今日已解决数”做成 SQL 聚合前端图表组件的接口返回结构只需要微调 map 映射即可。我把这个优化做完后用 1000 条测试数据验证了改动前后差距然后才放心提交代码。从那以后我重写功能前都会先看一眼原始 SQL 有没有全表扫强制让自己把这种习惯带进二次开发流程中希望帮到你。本文还有配套的精品资源点击获取
