微信小程序+SSM+MySQL设备报修系统：毕业设计部署与答辩全攻略

简介：一套基于微信小程序与SSM架构的设备故障报修毕业设计项目，面向计算机相关专业毕业生或需要快速搭建完整管理系统的开发者。项目包含用户、维修员、管理员三个角色，覆盖实验室管理、报修提交、维修报告、经验分享等核心流程，后台采用Java SSM框架并搭配MySQL数据库，小程序端使用微信开发者工具构建。资源共1255个文件，约49.98MB，以png/js/vue/java/sql等类型为主，涵盖前端页面素材、前后端源代码、数据库脚本、毕业论文文档及mp4演示视频，还有bat一键安装运行脚本，便于本地复现环境。论文部分涉及可行性分析、系统功能设计和数据库设计，成品可直接作为本科毕业设计参考或课程综合实践项目。已有131人学习/下载，适合毕业设计参考、SSM与小程序综合开发练习，以及设备报修类系统的二次开发基础。

1. 这个毕业设计到底给了你什么

如果你正为毕业设计选题发愁，又不想从零开始写一个前后端项目，那这套基于微信小程序 + SSM + MySQL 的设备故障报修系统，应该算是一条性价比很高的路。它的定位很明确：学生提交报修申请，管理员分配任务，维修人员处理并反馈结果，整个过程在微信小程序里闭环。和那些只能“增删改查”的 Demo 不同，这套系统的业务流是完整的，拿来改改就能成为一篇能自圆其说的毕业设计论文。

很多同学拿到这类项目包后，第一反应是“源码能跑就行”。但真实情况是：能跑只是一个起点，答辩的时候老师大概率会追问“订单状态是怎么流转的”“分页查询的 SQL 是怎么写的”“小程序端怎么保持登录态”。如果这些答不上来，项目再完整也白搭。所以我把这套系统的运行逻辑、部署步骤、踩坑点、答辩话术全部拆在下面，你照着走，不说拿优秀，但至少能踏踏实实走下答辩台。

2. 理解业务链路与数据库设计：别急着跑代码

2.1 报修系统的角色与状态机

做任何管理系统，第一件事不是写代码，而是把“谁在什么条件下能干什么事”理清楚。这套设备故障报修系统包含三类角色：学生（报修人）、维修工、管理员。学生登录小程序后提交报修单，填写设备名称、故障描述、位置和图片；维修工在小程序端或后台看到待处理工单，接单后更新处理状态；管理员负责分配工单、审核结果、管理设备和用户。

状态流转是这项目的核心亮点，也是答辩时最能体现你“做过”的地方。我的建议是必须理解这五个状态的顺序：待分配 → 待接单 → 维修中 → 已完成 → 已评价。有的系统还会加入“已驳回”或“待回访”状态，但核心流程就是前面五个。这里的难点是：状态更新不是单表修改，每次变更都要写入操作记录表。比如维修工从“待分配”直接改成“维修中”就不合理，必须在 Service 层做状态校验。代码里常见的做法是定义一个枚举类或者常量类。

public enum RepairStatus { WAIT_ALLOCATE(0, "待分配"), WAIT_ACCEPT(1, "待接单"), PROCESSING(2, "维修中"), COMPLETED(3, "已完成"), EVALUATED(4, "已评价"); private final int code; private final String desc; RepairStatus(int code, String desc) { this.code = code; this.desc = desc; } public static boolean canTransfer(int from, int to) { return (from == WAIT_ALLOCATE.code && to == WAIT_ACCEPT.code) || (from == WAIT_ACCEPT.code && to == PROCESSING.code) || (from == PROCESSING.code && to == COMPLETED.code) || (from == COMPLETED.code && to == EVALUATED.code); } }

这段代码的逻辑是：定义五个枚举值，每个值绑定一个数字 code 和描述文字；canTransfer 方法规定“只有相邻状态才能跳转”。这比直接在 Controller 里写 if else 要规范得多，也更符合 SSM 项目的分层思想。实际项目里你还会发现，硬件设备的状态是另一张表，和维修单状态是解耦的，改维修单状态时不要顺手把设备状态也改了，否则统计数据会乱。

2.2 核心数据表设计：设备、维修单、操作记录、用户

这类系统最怕的就是“一张表走天下”。如果所有数据都塞进一张大宽表，后期统计“每人修了多少单”“哪个设备故障率最高”会非常难受。我在部署这套系统的过程中看到，它的数据库至少有 8 张表，最核心的四张是：设备表、维修单表、操作记录表、用户表。设备表负责记录设备的基础信息，维修单表是业务主表，操作记录表是状态变更日志，用户表则区分角色。

CREATE TABLE repair_order ( id INT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL COMMENT '工单编号', device_id INT NOT NULL COMMENT '设备ID', reporter_id INT NOT NULL COMMENT '报修人ID', handler_id INT DEFAULT NULL COMMENT '维修工ID', fault_desc VARCHAR(500) NOT NULL COMMENT '故障描述', image_url VARCHAR(255) DEFAULT NULL COMMENT '故障图片', status TINYINT DEFAULT 0 COMMENT '0待分配 1待接单 2维修中 3已完成 4已评价', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_status (status), KEY idx_device (device_id), CONSTRAINT fk_order_device FOREIGN KEY (device_id) REFERENCES device(id) );

主键用自增 INT 没问题，但工单号建议单独做一列 order_no，格式比如 “BX20250611001”，方便在前端展示和检索。为什么不做成主键？因为主键是数据库内部的物理标识，工单号是业务标识，两者分开是表设计的基本功。这里我用 KEY idx_status 和 idx_device 建立索引，是为了让“按状态筛选工单”和“按设备查历史维修记录”这两个高频查询走索引，而不是全表扫描。

实际项目中你还会看到一张 repair_record 表，专门记录每次状态变更：谁在什么时间把工单从哪个状态改成了哪个状态。这张表的价值在于：答辩老师问“如果用户投诉维修人员没处理怎么办”，你就可以理直气壮地说“后台有操作日志，可以看到接单时间、完工时间、超时未完成记录”。这是加分项，也是很多同学忽略的设计。

2.3 前端页面与后台菜单的对应关系

拿到源码后你可能会疑惑：小程序端到底有哪些页面？后台管理端又有哪些菜单？我的建议是拿到代码后先画一张页面-接口-数据表的对应关系图，这张图画完，整个系统的结构就刻在脑子里了。小程序端页面一般包括：登录页、首页（设备分类列表）、报修表单页、维修进度页、个人中心页。管理员后台一般包括：待办工单管理、已处理工单、用户管理、设备管理、统计报表。

小程序调用后台接口时，接口路径一般以 /repair、/user、/manage 开头，分别对应报修业务、登录鉴权、管理后台。你可以在项目的 controller 目录里看到 RestController 类，里面有 @RequestMapping("/api/repair") 之类的注解。这一层的对应关系搞清楚，答辩时不管老师想听业务还是技术，你都不会被问倒。

3. 环境搭建与运行配置：把项目跑起来的完整步骤

3.1 从 JDK 到 Maven：先列一个环境版本清单

我见过太多同学卡在环境上：用 JDK 17 跑 SSM 项目，结果 Spring 版本不支持；用 MySQL 8 连数据库，驱动没更新；用 64 位电脑装了 32 位 JDK。这套基于 SSM 的项目通常比较“老派”，兼容性最好的是以下组合：JDK 1.8、Maven 3.6.3、Tomcat 8.5、MySQL 5.7。如果你已经装了更高版本，不一定不能用，但要确认项目里的配置文件没有写死版本号。

这套环境组合的取舍逻辑是“用最老的环境跑最稳的项目”。比如 MySQL 8.0 默认的排序规则是 utf8mb4_0900_ai_ci，而老项目 SQL 里可能写了 utf8_general_ci，导入时会直接报错。如果你只有 MySQL 8.0，可以把 SQL 文件里所有 CHARSET 相关部分改成 utf8mb4 再导入。JDK 版本同理，Spring 4.x 在 JDK 17 下会报 IllegalAccessError，这种问题重写代码不现实，换回 JDK 1.8 是最快的后悔药。

3.2 用 IDEA 导入 Maven 项目并配置 Tomcat

项目导入不是双击打开就算完。很多同学直接把源码目录拖进 IDEA，结果依赖没下载、配置文件没识别、启动报错。正确做法是：用 IDEA 的“从 Maven 模型导入”功能，选择项目根目录下的 pom.xml；如果是老项目没有 pom.xml，就找 build.gradle 或者直接导入 Web 项目结构。SSM 项目往往有 src/main/java、src/main/resources、src/main/webapp 这三个目录，导入后要先把这三个目录标记源目录，IDEA 才会正确编译。

# 在项目根目录执行 Maven 打包（跳过测试） mvn clean package -DskipTests

这行命令会做三件事情：清理 target 目录、重新编译源码并打包成 war、跳过单元测试。如果执行后 BUILD SUCCESS，说明依赖和源码没有大问题；如果报错，先看是下载依赖失败还是代码编译失败。依赖下载失败常见原因是网络连不上 Maven 中央仓库，可以换成阿里云镜像，在 Maven 的 settings.xml 里加镜像地址；编译失败则要具体看错误日志里的类名，一般是没有引 import 或 lombok 插件没装。

打完包之后，IDEA 里配置 Tomcat：点 Run → Edit Configurations → Tomcat Server → Local，在 Deployment 标签页里选 war 包，Application context 填 /repair。为什么要填 /repair？因为小程序端请求的后端地址可能写的是 http://localhost:8080/repair/api/...。如果你不改上下文路径，接口会全部 404。这是小白最容易踩的坑，项目本身没毛病，但路径对不上。

3.3 导入数据库与修改 db.properties 配置

数据库导入常用两种方式：命令行 source 和可视化工具导入。SQL 文件通常以 .sql 结尾，有的项目为了兼容 MySQL 5.7 和 8.0，会同时给出两个 SQL 文件，分别标注 mysql5.7.sql 和 mysql8.sql。如果你拿到的是单文件，直接执行导入，遇到兼容性问题再手动改 CHARSET。导入完成后，打开项目中的 db.properties 或 application.properties，把数据库连接串、用户名、密码改成你的本地环境。

jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/repair_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=你本地的密码

连接串里有三个参数需要关注：useSSL=false 是避免本地 MySQL 服务器没有配置 SSL 证书时连接报错；characterEncoding=utf8 是保证中文不乱码；serverTimezone=Asia/Shanghai 是解决 MySQL 8.0 默认时区的问题，老项目经常没写这一条，然后发现数据库时间比本地时间晚 8 个小时。

如果你用的是 MySQL 5.7，而且 SQL 文件是 utf8 格式，那这段配置基本不用动。强烈建议把数据库名建设成 repair_db，因为项目里所有 SQL 表和视图的关联都是基于这个库名，换库名容易导致 mapper.xml 里的缓存 SQL 失效或者触发权限错误。

3.4 微信开发者工具导入小程序端的三个细节

小程序端的工程目录一般和后台源码是分开的，可能是两个文件夹，也可能在源码包的 miniprogram 目录下。打开微信开发者工具，选择“导入项目”，把目录指到小程序所在的文件夹。这里需要强调三个细节：第一，AppID 可以先用测试号，不影响本地调试；第二，如果不校验合法域名这个开关没打开，所有请求都会被拦下，必须在详情 → 本地设置里勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”；第三，工具会要求选择语言模式，默认 JavaScript 即可，不要选 TypeScript，除非源码本身就用了 TS。

小程序端的接口地址通常写在 utils/config.js 或 app.js 里。你需要把它改成你的后端地址，比如 http://127.0.0.1:8080/repair。注意这里要用 127.0.0.1 而不是 localhost，因为小程序开发者工具在某些时候解析 localhost 会指向本身，导致请求直接打到自己身上。改完后重启开发者工具，再让小程序的登录页调用一次接口，能返回数据说明前后端已经通了。

4. SSM 框架的核心实现：从 Controller 到 Mapper 的完整闭环

4.1 登录鉴权与微信小程序登录态维护

微信小程序登录不是把用户名密码存下来那么简单。小程序的 wx.login 接口会返回一个 code，这个 code 需要后台拿去微信接口换取 openid。拿到 openid 后，后台自己生成一个自定义 token 返回给小程序端；后续每次请求，小程序把 token 放在请求头里，后台拦截器校验 token。这是目前最常见的方案，也符合 SSM 项目的业务要求。

@PostMapping("/login") @ResponseBody public Result login(@RequestBody LoginReq req) { String code = req.getCode(); String openid = wxService.getOpenid(code); User user = userMapper.selectByOpenid(openid); if (user == null) { // 首次登录，自动注册该用户 user = new User(); user.setOpenid(openid); user.setRole(1); userMapper.insert(user); } String token = UUID.randomUUID().toString().replace("-", ""); redisTemplate.opsForValue().set("token:" + token, String.valueOf(user.getId()), 2, TimeUnit.HOURS); return Result.ok().put("token", token).put("userId", user.getId()); }

这个接口做了三件事：调用微信接口换 openid，查用户表决定是自动注册还是直接登录，生成 token 并记录到 Redis。有些项目偷懒不用 Redis，直接用一个 Map 存 token，也能跑，但服务重启后所有登录态失效。这里用 Redis 是为了性能和数据持久性的平衡。实际做的时候还需要考虑 token 过期时间，2 小时比较合理，用户重新进入小程序时会自动调用静默登录接口续期。

4.2 报修单提交与图片上传的接口逻辑

提交报修单的接口需要注意三个点：图片先上传再提交表单、表单数据校验、故障描述脱敏或长度限制。图片上传通常使用 MultipartFile 接收文件，保存到本地磁盘或者外部云存储。本地保存的路径建议配置在 properties 文件里，不要写死，因为你交到答辩环境时路径可能完全不一样。

@PostMapping("/submit") @ResponseBody public Result submitRepair(@RequestParam("file") MultipartFile file, @RequestParam("deviceId") Integer deviceId, @RequestParam("faultDesc") String faultDesc, @RequestParam("handlerId") Integer handlerId, HttpSession session) { String realPath = uploadProperties.getPath(); String fileName = System.currentTimeMillis() + "_" + file.getOriginalFilename(); file.transferTo(new File(realPath + fileName)); RepairOrder order = new RepairOrder(); order.setDeviceId(deviceId); order.setFaultDesc(faultDesc); order.setImageUrl("/upload/" + fileName); order.setHandlerId(handlerId); order.setStatus(0); repairOrderMapper.insert(order); return Result.ok(); }

代码逻辑不复杂：先保存图片，再组装维修单数据入库。但有一个细节很多人没注意：图片路径保存的是相对路径，为了在小程序端能正常显示，后台要做静态资源映射。在 SpringMVC 配置类里重写 addResourceHandlers 方法，把 /upload/ 开头的路径映射到磁盘目录，否则图片会 404。还有一个隐蔽的坑：文件大小限制。Spring 默认上传大小是 1MB，用手机拍的照片动辄三四 MB，直接报文件过大。需要在配置里调整 multipart 限制。

4.3 分页查询与状态筛选：MyBatis 动态 SQL 的应用

后台管理端的工单列表往往是全系统最容易出 Bug 的地方。原因在于筛选条件太多：按状态、按报修人、按时间段。如果为每一种组合写一个独立方法，代码会爆炸。MyBatis 的动态 SQL 就是为此而生的，用 标签拼接 where 条件：

<select id="selectRepairPage" resultType="RepairOrder"> SELECT * FROM repair_order WHERE 1=1 <if test="status != null"> AND status = #{status} </if> <if test="deviceName != null and deviceName != ''"> AND device_id IN (SELECT id FROM device WHERE name LIKE CONCAT('%', #{deviceName}, '%')) </if> <if test="startTime != null"> AND create_time &gt;= #{startTime} </if> <if test="endTime != null"> AND create_time &lt;= #{endTime} </if> ORDER BY create_time DESC </select>

这里有一个老生常谈的“坑”：WHERE 1=1 被很多“优化大师”嗤之以鼻，但它确实能避免当所有条件都为空时 SQL 后面直接跟 WHERE ORDER BY 的语法错误。仔细观察这里的 deviceName 子查询，如果设备表数据量大，会有性能压力，建议改成 JOIN 或者 EXISTS。对于毕业设计这种量级，子查询完全够用。

分页插件的选择上，我建议直接用 PageHelper。在 Service 层调用 PageHelper.startPage(pageNum, pageSize)，然后紧跟着的 select 查询就会自动分页。要提醒的是 PageHelper 的线程局部变量问题：startPage 之后必须立即执行查询语句，中间不能再有任何无关的数据库操作，否则分页条件可能作用到错误的查询上。

4.4 Controller 层与 Service 层的开发规范

很多同学的代码把所有逻辑都写在 Controller 里，看起来跑得通，但一答辩就露馅。SSM 项目的分层规范是 Controller 只做参数接收、结果封装、异常捕获，业务逻辑在 Service 层，数据访问在 Mapper 层。这套系统里最值得你展示给老师看的，就是三层结构是否清晰。

Controller 层接收参数时建议用 POST + JSON 请求体。小程序端 wx.request 的 content-type 默认是 application/json，如果你后端的 Controller 用 @RequestParam 接收，数据传过来会直接报“参数缺失”；顺带一提，微信文档里明确的 contentType 选项并没有“application/x-www-form-urlencoded”的写法，这里极易翻车。改成 @RequestBody 接收对象，再配合 @Valid 注解做参数校验，就能同时解决数据格式和校验问题。

Service 层建议加上事务注解。比如在提交报修单这个动作里，涉及写维修单表、写操作记录表、可能还要扣减设备库存表。任何一个中间环节失败，前面写的数据就成了脏数据。标注 @Transactional(rollbackFor = Exception.class) 可以保证这些操作要么全部成功，要么全部回滚。答辩老师听到你说“我在 Service 层加了事务控制”，项目档次瞬间就不一样了。

5. 本地联调与常见问题排查：从“跑不通”到“稳如狗”

5.1 前端请求被拦截：解决跨域与 Session 失效

跨域是本地联调最容易遇到的问题。小程序的 web-view 不涉及跨域，但 wx.request 直接请求后端接口，要符合浏览器同源策略吗？实际上微信开发者工具在这块做了一些特殊处理，但如果你是在 H5 版后台调试，跨域问题绝对跑不掉。开发环境跨域是难免的，常见的做法是在后端加一个 CORS 过滤器，把所有来源都放行。

public class CorsFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletResponse resp = (HttpServletResponse) response; resp.setHeader("Access-Control-Allow-Origin", "*"); resp.setHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS"); resp.setHeader("Access-Control-Allow-Headers", "Content-Type, Authorization"); if ("OPTIONS".equalsIgnoreCase(((HttpServletRequest) request).getMethod())) { return; } chain.doFilter(request, response); } }

这里最容易被忽视的就是 OPTIONS 预检请求。当小程序端传递的请求头包含 Authorization 或 Content-Type: application/json 时，浏览器或者开发者工具会先发一个 OPTIONS 请求探测后端是否允许跨域。很多同学的过滤器没有直接放行 OPTIONS，结果日志里只看到一次请求，但前端报跨域错误，排查半天才发现是预检没通过。Session 失效的问题则是另一个大头：小程序端每次请求都带了同一个 Cookie 吗？如果你在登录后把 token 存储在 Storage 里，每次手动塞到 header，就不依赖 Cookie 了。如果你依赖 HttpSession 存储登录态，那么小程序端必须开启 Cookie,在 wx.request 里加上 withCredentials 配置。

5.2 数据库中文乱码与时区问题的排查方案

中文乱码是老 SSM 项目最常见的玄学问题。现象是：页面上传入的数据存进数据库后变成问号，或者从数据库查出来变成乱码。原因通常是三层字符集不一致：数据库连接串没加 characterEncoding=utf8、数据库表的 CHARSET 不是 utf8、项目本身的 JSP 页面或小程序请求头没指定 UTF-8。排查顺序应该是：先查连接串，再查表字符集，最后查 Tomcat 配置。

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8" />

这是 Tomcat 的 server.xml 配置片段。很多本地环境已经设置过 URIEncoding，但如果你用的是嵌入式 Tomcat 方式启动，就要检查一下项目内嵌的 Tomcat 版本是否默认 UTF-8。更隐蔽的一个坑是 HTML 表单默认提交的编码是 ISO-8859-1，但小程序端 wx.request 默认 UTF-8 是没问题的。如果你遇到部分接口中文正常、部分接口乱码，大概率是那一个方法没有设置 request.setCharacterEncoding("UTF-8")。用 SpringMVC 时，可以在 web.xml 里加一个 CharacterEncodingFilter，强制所有请求走 UTF-8。

5.3 上传图片失败：本地路径与静态资源映射

图片传不上去，一直报 404 或者 500，这是报修单系统的常见事故。500 可能是磁盘路径不存在，404 可能是上传成功但访问不了。路径问题在开发环境其实很好排查：看控制台打印的绝对路径，手动打开确认目录存不存在。如果路径是相对地址，上传到服务器或者换个目录启动项目，就可能因为不存在而报错。

解决方法是启动时自动创建目录。在配置类或者 ApplicationRunner 里写一个初始化方法，检查上传目录是否存在，不存在就创建。这一招对本地开发和他的电脑都有效，到哪里跑起来都不用手动建目录。另一个细节是图片文件名生成逻辑，我推荐时间戳拼接随机数，不要直接用原文件名。因为多个用户上传同名文件时，后上传的会覆盖前面的，而且中文文件名在不同操作系统间传输会出现编码问题。

String fileName = System.currentTimeMillis() + "_" + UUID.randomUUID().toString().substring(0, 8) + "_" + file.getOriginalFilename();

用一个时间戳加短 UUID 保证文件名唯一，前缀保留原始文件名，方便人工识别。写到这里想到一件事：上传目录尽量放在项目外部，不要放到 Tomcat 的 webapps 下。因为项目重新部署时旧文件会被清理，你有演示数据也会被删掉。放在一个独立的 docs 目录或者 data 目录，项目重启不会动它，答辩前上传的图片不至于在演示时丢失。

5.4 小程序端请求返回 404/500 时如何快速定位

产生了 404，第一时间不要看前端，打开后端的控制台日志，几乎都能找到 No mapping found 的报错。这类情况多半是 URL 和 Controller 的 @RequestMapping 不匹配。前端请求的是 /api/repair/submit，后端 Controller 类注解是 /repairController，方法注解是 /submit，实际映射就是 /repairController/submit，前端拼的路径当然对不上。

500 则要看异常类型：如果是 NullPointerException，检查参数有没有传全；如果是 SQLIntegrityConstraintViolationException，外键对应的数据不存在；如果是 TimeoutException，看一下数据库连接池有没有耗尽。经验法则：先把后端日志级别改成 DEBUG，再把 log4j 或 logback 的 XML 配置打开，基本能把问题缩小到哪一行代码。要在本地联调前把所有日志打开，装一个“全局异常处理器”，把后台错误信息返回给小程序端，比在后端日志里一遍遍翻要省心得多。

6. 答辩演示与功能扩展：让这个项目真正属于你

6.1 演示时的必走流程与关键点铺垫

答辩演示不是把所有功能点一遍，而是有节奏地展示“你理解这个业务系统”。我的建议是演示路径这样安排：先展示学生端小程序，从提交报修单开始，带一张真实现场拍的故障照片；然后切换到管理后台，说明“我这边看到一条新工单，状态是待分配”；接着分配给自己，去维修工账号接单，修改处理状态；最后回到小程序端查看进度，看到状态变成了“已评价”。

这个流程走下来，老师能看到完整闭环，同时每个环节都在表达“状态机设计”。在演示前，请务必准备好一个“预置数据”的数据库文件：至少有 5 张设备、3 个学生账号、2 个维修工账号、10 条不同状态的维修单。不要展示空白数据库，那会让老师觉得项目没有实际测试过。演示时如果现场网络不好，建议把微信小程序端的域名校验关掉，或者把图片走本地加载，否则图片加载不出来会非常尴尬。

6.2 两条高性价比的代码优化方向

在保证原项目能运行的前提下，有两个改动性价比特别高：一是给列表页增加搜索功能，二是把统计报表做成图表。搜索功能的本质是复用 MyBatis 的动态 SQL，你在后端加一个模糊查询字段，小程序端加一个搜索框，前后不超过 30 分钟。统计报表则可以用 ECharts 或 AntV，把维修单按状态分组、按设备分类计数、按周统计工单量。这类扩展展示在答辩上是加分项。

@GetMapping("/analysis/countByStatus") @ResponseBody public Result countByStatus() { List<Map<String, Object>> list = repairOrderMapper.countGroupByStatus(); return Result.ok().put("data", list); }

对应的 SQL 就是 SELECT status, COUNT(*) FROM repair_order GROUP BY status。这种写法的好处是前端拿到结果后直接渲染成饼图或者柱状图。毕业设计论文里也能顺势多写一小节的“数据分析模块设计与实现”。

6.3 想要“变原创”的底线建议

很多同学拿到源码后第一反应是“怎么改成自己的”。我不建议你把类名变量名大改一遍，那是效率最低且风险最高的做法。正确方式是在原有结构上加一个自己的功能点，并且把新功能的 UML 流程图画清楚。常见容易加的功能有：报修预约时间、维修完成后评价打分、设备巡检提醒。这三个功能都建立在已有表和状态流之上，不需要重构原代码，又能体现你的个人工作。答辩时也坦然一点：项目是基于一套参考设计扩展来的，我做的主要工作是理解业务流并扩展了某某模块。这比硬说是“纯原创”然后被老师问倒要体面得多。

6.4 最后的检查清单

答辩前再检查一次：数据库初始化脚本能不能在干净环境跑通；项目代码里有没有包路径写死成绝对路径的配置；小程序端的请求地址是不是指向了你演示用的后端；上传目录是否存在并且有测试图片；同一个流程至少完整走三遍，确认没有偶发 500。这是我自己的习惯：每次演示前必须录屏一遍完整流媒体，用来确认环境是“冷启动”能跑的。很多项目在自己的电脑上能跑是因为你之前运行过，缓存和状态都在，换了台电脑或者清了缓存就露馅。交付前做一次冷启动测试，就像交车前试驾冷车一样必要。

希望这些经验能帮你少走点弯路。如果后面你在部署或答辩时又遇到奇怪的问题，欢迎回来告诉我是怎么解决的。希望帮到你。

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