每年选题季，我这边总会收到几份标题几乎一样的压缩包，名字都叫“校园故障报修系统”，里面塞着源码、一份数据库脚本，再配一份开题报告。多数情况下这三样东西彼此对不上号：开题里列了二十来项功能，源码里真正跑得起来的只有七八项；数据库脚本导进去直接报错；开题报告的“国内外研究现状”整段读下来全是百科句式，一查重就红。更麻烦的是，很多同学拿到一份现成的校园故障报修系统源码，连业务链路都没走通就开始改界面、换主题色，改到答辩前一晚才发现派单逻辑根本跑不起来。
这篇东西想解决的问题很具体：把“校园故障报修系统”这个题目从一句话拆成能落地的东西——业务链路怎么走、数据怎么建模、开题报告怎么写得像自己想的、源码拿到手怎么读怎么改怎么讲。适合三类人看：正在做这个毕设题目的同学、需要从零写一套工单类系统的开发者、以及要把类似系统交付给后勤部门实际用起来的人。下面涉及的实现细节，凡是原文没给的，都是我按“一个能跑起来、能过答辩、后续还改得动”的标准补的，属于常见实践，不是唯一答案，各位按自己的技术栈换算即可。
1. 先把“报修”这条业务链走通，再谈技术实现
1.1 一张纸质报修单上的六个角色与四条流转线
很多人做这个系统时，脑子里的流程只有一条直线：学生提交、管理员看到、修好、结束。真去后勤跟一天班就会发现，纸质报修单的流转比这复杂得多。我在某高校后勤处蹲过半天，光是“派给谁”这一个动作就分了三种情况：水电类直接派给值班电工、网络类要转到信息中心、空调和门窗类得先看是不是在保修期内，保修期内要走厂家流程。这些分支如果不提前想清楚，代码写到一半就会开始到处打补丁。
把角色摊开来看，一个能实际用的校园故障报修系统至少要容纳六类人：报修人（学生、教职工、宿管）、受理员（值班室，负责初审、判断是否属于服务范围）、维修工（按工种拆分，水电、木工、网络、空调、保洁）、值班主管（派单、改派、加急、超时催办）、验收人（通常是报修人本人，重要工单再加主管抽检）、系统管理员（账号、区域、故障类型字典、通知模板）。角色定完，权限才有落脚点，否则后面写权限控制就只能靠 if-else 硬编码。
流转线同样不止一条。正常闭环是“提交→受理→派单→接单→维修中→完工待验收→验收通过→评价”，这条线占八成流量。剩下三条是异常线，也是真正拉开系统水平的地方：退回线（受理员判断描述不清或不属于服务范围，退回补充，报修人改完重新提交，工单号不变）、挂起线（缺配件、需要外委施工，工单挂起并记录预计恢复时间，恢复后回到维修中）、撤销线（报修人自己撤销，或者长时间无人处理由系统定时关闭）。
这四条线里，撤回和退回最容易做错。我见过一份源码，退回操作直接把工单状态改成“待提交”，结果原来那条处理记录也被覆盖了，报修人打开详情页看到的是一张空白单子。正确做法是工单主表状态回退，但操作日志表只增不改，每一次退回都留一条带原因和操作人的记录，详情页按时间轴展示。这个小设计在答辩时很好讲，因为它体现的是“数据可追溯”的思路，而不是简单的增删改查。
1.2 工单状态机是这个系统真正的骨架
界面可以抄，代码可以套，唯独状态机必须自己画。状态机画错的后果是：代码里到处判断status == 3还是status == 4，改一个需求要翻二十个文件。我的建议是先把状态枚举定死，再为每一次转移写清楚“谁能触发、前置条件是什么、触发后写入什么记录”。
一份比较稳妥的状态枚举大致如下：
| 状态码 | 状态名 | 说明 | 允许的下一个状态 |
|---|---|---|---|
| 10 | 待受理 | 报修人已提交 | 退回补充、已受理、已撤销 |
| 15 | 退回补充 | 受理员要求补充信息 | 待受理、已撤销 |
| 20 | 已受理 | 初审通过，等待派单 | 已派单、已撤销 |
| 30 | 已派单 | 指定了维修工 | 已接单、已改派 |
| 40 | 维修中 | 维修工已接单到现场 | 已挂起、完工待验收 |
| 45 | 挂起 | 缺件或外委 | 维修中 |
| 50 | 完工待验收 | 维修工提交完工说明 | 已验收、返工 |
| 60 | 返工 | 验收不通过 | 维修中 |
| 70 | 已验收 | 验收通过 | 已评价、自动归档 |
| 80 | 已评价 | 报修人给出评分 | 无 |
| 90 | 已撤销 | 报修人或系统关闭 | 无 |
状态码之间留出空档（10、15、20 这种步长为 5 或 10）不是强迫症，是为了以后插入中间态时不用全表改数据。我踩过一次坑：早期用 1、2、3 连续编号，后来要加“待分配工种”这一态，只能把后面所有状态整体后移，历史数据全得写迁移脚本。
有了这张表，代码里就只允许一个入口改状态。Java 侧通常写成一个WorkOrderStateMachine类，方法签名类似boolean transfer(Long orderId, OrderStatus from, OrderStatus to, Long operatorId, String remark)，内部先校验from和to是否在允许集合内，再校验操作人角色是否有该转移权限，最后写主表、写日志、发事件。任何业务代码想改状态，都必须走这个方法。前端同理，把“当前状态能显示哪些按钮”做成一份配置表下发，别在页面上写死 if。
为什么一定要这么较真？因为工单类系统的需求变更是常态。后勤部门用两周就会提出“我们要加急单”“我们要区分教学区和宿舍区”“维修工请假了要批量改派”。状态机收敛得越干净，这些需求进来时改的地方越少，答辩被问到“如果增加一个状态怎么办”，你能直接指给对方看枚举和转移表，这比背概念有说服力得多。
1.3 功能清单的三档分级法：必须有、应该有、最好别做
开题报告里最容易失控的就是功能清单。二十项、三十项列得很爽，写代码时才发现每一项都要联调。我一般建议按三档切：
必须有（缺了系统不成立）：报修提交（含图片）、工单列表与详情、受理与派单、维修工接单与完工、验收与评价、基础的用户与角色管理、故障类型和区域字典维护。这八项凑齐，系统才闭环。
应该有（决定好不好用）：消息通知（站内信 + 可选短信）、超时未处理提醒、工单搜索与多条件筛选、处理时间轴、简单的数据统计（按区域、按类型、按工种、按月）。这些是加分项，也是答辩时能讲出“考虑过实际使用场景”的地方。
最好别做（投入产出比极低）：地图选点定位、人脸识别、智能派单算法、微信小程序 + App + 网页三端、实时聊天。这几项随便拎一个出来都能吃掉一半工期，而且小样本数据下算法效果根本体现不出来。我见过有同学在答辩现场演示“智能派单”，评委问训练数据从哪来的，答不上来，非常吃亏。真想体现算法思维，做一个基于工种匹配度 + 当前未完成工单数 + 距离权重的简单打分排序就够了，二三十行代码，讲清楚权重怎么定，比硬套一个模型强。
2. 技术选型与数据建模：决定后期返工量的一步
2.1 三套主流技术栈的取舍逻辑
做这类系统，市面上大致三条路：Java 单体（后端渲染模板）、前后端分离（后端接口 + 前端框架）、低代码平台搭。三条路我都试过，各自的适用场景差别很大。
| 方案 | 典型组合 | 上手成本 | 适合谁 | 主要风险 |
|---|---|---|---|---|
| 后端渲染单体 | 后端框架 + 模板引擎 + 关系库 | 低 | 时间紧、只求闭环 | 页面交互粗糙，前端亮点难做 |
| 前后端分离 | 后端接口 + 前端框架 + 关系库 | 中 | 想展示工程规范、要做多端 | 跨域、鉴权、部署三处容易卡住 |
| 低代码平台 | 可视化表单 + 流程引擎 | 很低 | 一周内要交东西 | 底层逻辑讲不清，被追问就露怯 |
我更倾向前后端分离，不是因为先进，而是因为它把“接口契约”这件事摆到了台面上。开题报告里写“系统采用前后端分离架构，后端提供 RESTful 接口，前端通过 Axios 调用”，接下来就必须回答接口怎么鉴权、异常怎么统一返回、跨域怎么处理。这三个问题答得出来，说明你真的动过手；答不出来，架构描述就只是贴标签。
如果选前后端分离，有几个默认配置值得提前定好：统一响应体（code、message、data三段式）、统一异常处理（业务异常和系统异常分开，前者返回可读提示，后者记日志返回兜底文案）、令牌鉴权（登录后下发令牌，前端拦截器统一带上，后端过滤器校验）、跨域配置（开发期放开指定来源，别图省事写通配）。这几样加起来不到两百行代码，但能让后面所有接口的开发效率翻倍，也方便你写接口文档。
至于数据库，这类系统数据量很小，一个学院一年工单量也就几千条，关系型数据库完全够用，不需要引入缓存和搜索中间件。真要提性能，规范地建索引（工单表的报修人、状态、创建时间、维修工四个字段）、避免在列表页做 N+1 查询，效果比加缓存明显得多，而且好讲。
2.2 六张核心表怎么切，字段怎么定
数据建模这块，我见过最常见的两种极端：一种是把所有信息塞进一张工单表，字段四十多个，评价内容、配件清单、处理记录全堆一起；另一种是过度范式化，光字典表就建了十几张，写个查询要 join 六张表。这两种都难受。比较平衡的做法是六张主表加若干字典表。
-- 工单主表：只放工单本身的稳定属性 CREATE TABLE t_work_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT '对外单号，如 BX202405120001', reporter_id BIGINT NOT NULL COMMENT '报修人', area_id BIGINT NOT NULL COMMENT '区域，如3号楼', location VARCHAR(120) NOT NULL COMMENT '具体位置描述', fault_type_id BIGINT NOT NULL COMMENT '故障类型字典', title VARCHAR(100) NOT NULL, content TEXT COMMENT '详细描述', urgency TINYINT NOT NULL DEFAULT 1 COMMENT '1普通 2较急 3紧急', status SMALLINT NOT NULL DEFAULT 10, handler_id BIGINT COMMENT '当前受理人', worker_id BIGINT COMMENT '当前维修工', submit_time DATETIME NOT NULL, accept_time DATETIME, finish_time DATETIME, deadline DATETIME COMMENT '处理时限，超时用于提醒', version INT NOT NULL DEFAULT 0 COMMENT '乐观锁', UNIQUE KEY uk_no (order_no), KEY idx_reporter (reporter_id, status), KEY idx_worker (worker_id, status), KEY idx_status_time (status, submit_time) ) COMMENT '工单主表';主表刻意不放评价内容和处理明细。评价单独一张表（一对一），处理记录单独一张表（一对多），配件消耗再单独一张。这样拆的好处是主表足够窄，列表页查询快；坏处是要多写几个 join，但工单详情页本来就要多次查询，可以在服务层组装成一个聚合对象返回。
处理记录表是这套系统里价值最高的一张表，它的设计直接决定详情页的时间轴好不好看：
CREATE TABLE t_order_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, from_status SMALLINT, to_status SMALLINT NOT NULL, action VARCHAR(32) NOT NULL COMMENT 'SUBMIT/ACCEPT/DISPATCH/...', operator_id BIGINT NOT NULL, operator_role VARCHAR(16) NOT NULL, remark VARCHAR(500), create_time DATETIME NOT NULL, KEY idx_order (order_id, create_time) ) COMMENT '工单流转日志，只增不改';这张表只增不改不删，是“数据可追溯”的物理体现。答辩时把这条设计讲出来，再演示一下详情页时间轴，效果比讲十个功能点都实在。
其他几张表简单带一句：用户表（含角色标识）、角色权限表（角色到菜单/接口的映射）、字典表（区域、故障类型、工种，用 type_code 区分，一张表存所有字典，省得建一堆）、附件表（工单 id、文件路径、上传人、上传时间）、评价表。附件表单独拆出来而不是在工单表存逗号分隔的路径，是因为一个工单可能上传多张图，而且要记录是谁在什么阶段传的——维修工完工时补传的现场照片和报修人提交时的照片，价值不一样。
2.3 图片上传与存储：最容易在上线演示时翻车的环节
这个环节看着不起眼，翻车率却最高。我统计过自己看过的十来份源码，图片存储方案踩坑的比例超过一半，问题集中在三处：文件存本地但路径写死成绝对路径，换台机器就 404；文件名用原始名，中文和空格直接让服务端解析失败；上传大小没限制，学生手机拍的图动辄七八兆，传上去页面转圈转到超时。
稳妥的处理是：文件统一存到可配置的目录（配置项里写相对路径，启动时解析成绝对路径），落盘文件名用“日期目录 + UUID + 原扩展名”，数据库只存相对路径。上传接口做三件事——校验扩展名白名单（jpg、jpeg、png、webp）、校验文件头魔数（防止改扩展名伪装）、限制单文件大小（比如 5MB）和单工单附件数量（比如 6 张）。前端在上传前做一次压缩，把长边压到 1600 像素以内，这一手能让上传成功率显著提升，学生用手机拍的图往往三五千像素宽。
还有一个细节：图片访问权限。工单图片理论上只有相关人该看得到，如果直接把上传目录暴露成静态资源，任何人猜到文件名就能访问。小系统里常见的折中做法是文件名用 UUID（猜不到）+ 通过后端接口转发读取并校验登录态。后一种更严谨，代价是图片加载走应用服务器，但校园场景并发很低，完全扛得住。如果决定用静态目录直出，至少在报告里说明这是一个已知的简化，别等评委问起来才临时想理由。
3. 开题报告不是凑字数，而是把设计决策讲成故事
3.1 选题背景：从“宿舍灯管坏了”写到“可量化的管理问题”
绝大多数开题报告的背景部分是这么写的：“随着高校规模的不断扩大，后勤管理工作日益繁重，传统的报修方式已经不能满足需求……”这段话本身没错，但它的问题是换成“食堂管理”“图书管理”也一样成立，一看就是套的。
真正有说服力的背景要落到可量化、可验证的现象上。我给的建议是先做一轮小范围观察或访谈，把现象记成数字。比如：某栋宿舍楼一周内登记在纸本上的报修记录有 37 条，其中 9 条没有处理结果的签字；值班室平均每天接到 20 通报修电话，其中约三分之一是重复催问；维修工每天上午要回值班室两次取单子，往返耗时约 40 分钟。这些数字不需要多精确，但必须是你自己数的、能说清来源的，写进报告里就是“调研发现”，而不是“众所周知”。
然后把这个现象翻译成管理问题：信息不对称导致重复沟通成本高、纸质记录无法统计导致资源调配缺乏依据、处理过程无留痕导致责任界定困难。三个问题对应三个系统能力：线上提交与状态可见、多维度统计报表、全流程日志。这样一来，后面的功能设计就不是拍脑袋列的，而是从问题推出来的。答辩时评委会问“你为什么做这个功能”，你有话可答。
我特别想提醒一句：背景部分不要写“提升学校信息化水平”“推进智慧校园建设”这类大词。这类表述太空，写上去只会稀释你自己的调研价值。把篇幅留给那 37 条记录和 40 分钟往返，比写三段宏大叙事有用。
3.2 研究现状要“找缝”而不是“报菜名”
国内研究现状这部分，最常见的写法是把几篇论文的摘要改写成一段话，读起来像文献列表。评委看一眼就知道你没读。比较有效的做法是“分类 + 找缝”：先把已有做法归成几类，再指出每类在校园报修这个具体场景下的不足。
大致可以这么分：第一类是通用的工单管理系统，功能全但配置复杂，部署和维护成本对后勤部门偏高；第二类是基于即时通讯群组的报修方式，上手零成本但信息碎片化，无法统计和追溯；第三类是学校自建的老系统，往往只覆盖提交和查看，缺少派单和验收环节。三类的共同短板是：没有针对校园特有的多工种、多区域、保修期判断做适配，工单流转到“需要外委”这种异常分支时就断了。
找到缝之后，你的定位就清楚了：不追求功能大而全，而是把校园场景下的异常流转做扎实。这种定位听起来不宏大，但它诚实、具体、可验证，反而更容易被认可。写的时候注意，参考文献要真去读摘要，引用时说明“该方案在某某方面有效，但在某某场景下存在不足”，别整段搬运。
3.3 技术路线与进度排期怎么写才可信
技术路线部分，很多人写成技术栈罗列：用了什么框架、什么数据库、什么工具。这不算路线，路线是“先做什么、为什么这个顺序、每步产出什么”。我习惯按层次写：数据层（建表、字典初始化、造测试数据）→ 服务层（用户与权限、工单状态机、附件、通知）→ 接口层（按角色划分接口组）→ 展现层（三类角色的页面）→ 联调与部署。每一层写清楚依赖关系和验收标准，比如“数据层完成的标志是能通过脚本一键初始化出一个可登录、可提交工单的环境”。
进度排期要留缓冲。我见过太多排期表把每天都填满，结果第三周卡在一个跨域问题上，后面全线崩。稳妥的做法是按周排，每周留出一天机动，并且把“联调”单独列成一周而不是塞在开发周里。总周期如果是十二周，大致可以这么分：需求与建模两周、后端核心三周、前端页面三周、联调与异常流程两周、文档与演示准备两周。注意异常流程（退回、挂起、撤销、超时关闭）要单独留时间，这些恰恰是最容易漏的。
还有一个小技巧：排期表里写上“里程碑交付物”，比如第四周末产出可运行的登录 + 提交 + 列表，第八周末产出完整闭环。这样即使后期有延误，你也有可展示的阶段性成果，不至于答辩时只有一个跑不起来的半成品。
3.4 创新点的合理包装
小系统的创新点不必是算法突破，把“针对性设计”讲清楚就够了。以这个题目为例，可以提炼三个方向。
一是异常流程的完整覆盖。多数同类系统只做正常闭环，你把退回、挂起、撤销、超时自动关闭四条线补全，并给出状态转移表和日志留痕机制，这就是实打实的设计工作量。
二是时限与超时机制。按故障类型和紧急程度设置不同的处理时限（比如漏水 2 小时、灯管更换 24 小时、门窗维修 48 小时），超时自动提醒并升级到主管。这个设计的价值在于它把“服务承诺”变成了系统里的一个字段，可以统计达标率。
三是轻量的派单辅助。不做复杂的智能调度，只做一个打分排序：工种匹配度、当前在手工单数、区域就近程度三项加权，权重可配置。实现简单，但能讲清楚权重为什么这么定，比空谈算法靠谱。
包装的原则是：只讲你真做了的，且能说清“为什么这么设计”。答辩现场最怕的是把没做的说成做了，评委追问两句就崩。宁可创新点少一个，也别虚。
4. 拿到源码之后的三天：读、改、讲
4.1 第一天：跑通与断点，把调用链画出来
拿到一份现成的校园故障报修系统源码，第一件事绝对不是打开编辑器改界面，而是让它先跑起来。顺序是：看依赖清单确认版本、建库导入脚本、改配置文件里的数据库连接和上传目录、启动后端看日志、启动前端看接口地址。这五步里任何一步报错都别急着搜解决方案，先看完整错误栈的最后三行，八成能定位。
跑通之后做第二件事：在“提交报修”这个动作上打断点，从控制器一路跟到数据库，把调用链画在纸上。一条完整的链至少经过：前端表单校验 → 接口参数校验 → 权限拦截 → 业务服务 → 附件处理 → 主表写入 → 日志写入 → 通知触发。哪一环缺了、哪一环是空的实现，一眼就能看出来。我见过不少源码，通知模块只有一个空方法，前端却挂着“消息中心”的入口，点进去永远空白，这种地方答辩时必被问。
画调用链还有个附加好处：你能快速判断这份代码值不值得改。如果业务逻辑全写在控制器里、SQL 拼在字符串里、没有统一异常处理，那基本是“能跑但改不动”的类型，与其在它上面改，不如保留表结构和页面，重写服务层。判断标准很简单：加一个新功能（比如“加急”），如果要在五个以上文件里改，就说明结构有问题。
4.2 第二天：权限与状态的最小改造
大部分现成源码的权限是写死的：登录时判断角色字段，等于 1 是管理员、2 是维修工、3 是学生，然后页面上用 v-if 藏按钮。这种写法能演示，但经不起追问。最小成本的改造是把三样东西抽出来成配置：角色定义、菜单与接口的对应关系、状态到可执行动作的映射。
具体做法不必上完整的权限框架，用“角色-权限码”两张表加一个拦截器就够。权限码用“模块:动作”命名，比如order:dispatch、order:finish、order:evaluate。拦截器在请求进来时，根据当前用户角色查权限码集合，比对接口上标注的权限码。前端拿同一份权限码集合控制按钮显示。这样改完，回答“如果要新增一个‘后勤主管’角色怎么办”时，你可以说“加一条角色记录、配一组权限码，不改代码”，这话很有分量。
状态部分同理，把状态转移规则收敛到一个地方。哪怕原来代码里到处都是if (status == 3)，你也可以新增一个状态机类，然后逐个替换。替换过程中如果发现某处状态判断和状态机表不一致，那正好是原代码的 bug，顺手修掉并在报告里记一笔，这叫“代码重构与缺陷修复”，是加分项。
改造的节奏建议是：一次只改一个维度，改完立刻跑一遍主流程回归。别同时动权限和状态机，出了问题分不清是谁引起的。我吃过这个亏，两个改动一起上，最后定位问题花了一整天。
4.3 第三天：设计一套三分钟能讲完的演示脚本
答辩演示最常见的失败方式是从登录页开始，一步一步点，点到第五分钟还在填表单。评委会疲劳。反过来，脚本设计得好，三分钟就能把系统价值讲透。
我的脚本结构是“一个工单的一生”：先在报修人账号提交一条带图工单（20 秒，重点展示图片、位置、紧急程度）；切到受理员账号，展示待办列表、退回调这个操作、再受理派单（40 秒，重点展示状态变化和日志时间轴）；切到维修工账号，接单、上传现场照片、填写完工说明（40 秒）；切回报修人，验收、评价（20 秒）；最后打开统计页，展示按类型和区域的分布、超时工单数（40 秒）。全程 3 分钟内，五个角色全覆盖，四条异常线里至少演示一条退回线。
演示前必须做的准备：造好测试数据（至少 30 条工单，覆盖各种状态，别让统计页空空如也）、准备两个浏览器（不同账号同时登录，避免反复登出）、关闭所有通知弹窗和即时通讯软件、把数据库备份一份（现场误操作可以立刻恢复）。还要准备一个“如果现场网络断了”的备用方案：本地起服务 + 录一段两分钟的录屏。这不是多虑，我见过两次现场网络出问题的情况。
5. 几个真踩过的坑与实测有效的处理方式
5.1 状态并发：两个人同时抢单会怎样
派单和接单这两个动作天然存在并发。假设两个维修工同时点“接单”，代码里是先查状态再更新，中间没有锁，结果就是两人都判断成功，最后一人覆盖一人，工单归属错乱，另一个人白跑一趟。这种问题在小规模测试里几乎不会出现，一旦真用起来就会暴露。
处理方式有两种，按成本从低到高。第一种是乐观锁：工单表加version字段，更新时带上版本号条件，UPDATE ... SET status = 40, worker_id = ?, version = version + 1 WHERE id = ? AND version = ? AND status = 30，影响行数为 0 就说明被别人抢先了，返回“该工单已被他人接单”。这种方式不改架构，代码量很小，适合绝大多数场景。第二种是状态机的条件更新：直接在 SQL 里把前置状态写进条件，AND status = 30，同样看影响行数。两种可以叠加使用。
需要提醒的是，前端也要配合。接单按钮点下去后立即置灰并显示加载态，防止用户连点。后端接口做幂等处理，同一个维修工重复提交同一工单的接单请求，直接返回成功而不是报错。这个细节能省掉大量“我点了没反应就多点了几下”引发的脏数据。
5.2 消息通知：别让推送成为答辩现场的意外
通知是个典型的“看着简单做着烦”的模块。很多源码里通知是同步发送的：业务方法里直接调发送接口，发送失败抛异常，结果主流程回滚。工单提交成功但通知没发出去，用户看到的是“提交失败”，实际上数据库里已经有记录了，再点一次就是两条。
正确做法是把通知从主流程里摘出来：业务方法只负责把事件写进一张通知任务表（或者内存队列），由定时任务或异步线程去消费发送，失败重试三次后标记为失败并记录原因。这样通知的成败不影响主业务，出问题也能查。
还有一个演示隐患：如果你接了真实的短信或第三方推送，答辩现场很可能因为余额、频率限制、网络策略等原因发不出去，页面卡在那里转圈。稳妥的做法是默认用站内信，短信作为可开关的扩展，配置文件里一个开关控制。演示时只演示站内信，红点提示 + 消息列表，效果足够，风险为零。这个小决定我在三个项目上都用了，从来没在现场掉过链子。
5.3 统计报表：SQL 聚合和代码聚合的边界
统计页是答辩的收尾亮点，也是最容易出性能问题的地方。常见写法是把所有工单查出来塞进内存，然后用代码循环分组计数。数据量小的时候没问题，一旦测试数据造了上千条，页面打开要等好几秒，演示时非常尴尬。
正确的边界是：能在数据库里聚合的，绝不在代码里循环。按类型分布一条GROUP BY fault_type_id就够了，按月份统计用日期函数分组，平均处理时长用时间差函数求平均。真需要复杂计算的（比如按时限计算达标率），可以在 SQL 里先算出每条工单的时长和是否达标，再在外层聚合，仍然不需要把明细拉到应用层。
另外提醒一个数据陷阱：统计“平均处理时长”时，要把仍在处理中、已撤销的工单排除掉，否则均值会被未完成的工单严重拉偏。这个细节在报告里写一句，能体现你想过指标口径，比单纯堆图表有意义。图表不用多，四五个够用：类型分布饼图、区域分布柱状图、近六个月工单量趋势、超时工单数、满意度分布。
最后分享一点个人体会。这套系统我前后看过、改过、也从头写过几遍，感受最深的是：决定它好不好用的从来不是技术栈新不新，而是你有没有认真对待那几条异常流程。正常提交到验收这条路，任何一个会写增删改查的人都能做出来；退回时信息怎么保留、挂起时怎么通知、超时了怎么升级、改派后原维修工的工作量怎么算，这些才是这个题目真正的分量所在，也是开题报告里最值得写、答辩时最值得讲的部分。源码和开题报告从来不是两份独立的东西，它们应该讲的是同一个故事——你发现了什么问题，用什么结构去解，为什么这么解。
