简介：一套微信小程序消防隐患在线举报系统，是针对消防隐患网络举报场景的完整毕业设计资源，适合高校学生用于课程设计、毕业设计或项目实战练习。系统基于SSM（Spring、SpringMVC、MyBatis）架构，前端包含微信小程序和Vue后台管理，覆盖用户注册登录、隐患填报、图片上传、举报审核、隐患跟踪与结果反馈等核心模块，有助于深入理解小程序开发、分层后端设计与数据库建模。资源压缩包约20.11MB，共1060个文件，类型涵盖小程序页面、Vue后台界面、Java后端代码、配置文件和SQL数据库脚本，并附带论文与演示文档、图标素材以及一键安装、运行与构建脚本，目录结构清晰便于对照学习。目前已有210人学习浏览，适合需要快速搭建同类举报或工单类应用，并希望从源码与数据库中获取完整实现思路的读者参考。
1. 消防隐患举报系统为什么值得拆开看一遍
这套微信小程序消防隐患在线举报系统，表面上是上报、审核、处理三件事，落到代码里其实是两条主链路：后端要处理图片附件和状态流转，小程序端要处理登录态和表单提交。难得的是，它把这两条链路完整地串在了一起，而不是只给一个空壳前端。拆开资源时能看到 main.css.bak、IndexAsideStatic.vue.bak 这类文件，说明后台管理端保留了组件级别的备份习惯，后端走的是 SSM。对于正处在毕业设计、数据库课程设计阶段的人来说，这是一个能直接跑起来的微信小程序项目实例；对于已经工作、想补全 SSM 和 MyBatis 源码级理解的开发者，它同样提供了可复现的参考。
2. SSM 后端请求链路：先看懂举报提交这条主路径
2.1 举报接口的 Controller 层写法
拿到项目先不急着启动，第一步是找到举报相关的 Controller，把一次请求从 URL 到数据库的路径画出来。这套系统里最常见的入口是/api/report/submit，用 SpringMVC 的注解路由接收小程序端的 JSON 数据。
@RestController @RequestMapping("/api/report") public class ReportController { @Autowired private ReportService reportService; @PostMapping("/submit") public Result submit(@RequestBody ReportDTO dto) { if (dto.getAddress() == null || "".equals(dto.getAddress())) { return Result.error("隐患地址不能为空"); } if (dto.getType() == null) { return Result.error("隐患类型不能为空"); } String reportNo = "XF" + System.currentTimeMillis(); Long id = reportService.addReport(dto, reportNo); return Result.ok(id); } }这段代码在 Spring 4.3 之后可以写成@RestController，而早期 SSM 项目里更常见的是@Controller配合@ResponseBody。两者在路由、拦截器、异常处理上的行为基本一致，所以不用纠结。真正容易被问到的是参数校验的位置：这里把必填校验放在 Controller，只是第一道闸门，业务规则校验应该继续下沉到 Service，例如同一个地址短时间内重复举报、隐患类型是否在字典范围内。
2.2 MyBatis 动态 SQL 与后台列表分页
举报列表是后台管理端最常用的页面，筛选条件通常是状态、关键词、时间范围。如果为每一种组合写一条 SQL，后期维护会非常痛苦。这个场景下，最常见、也最容易讲清楚的方案是 MyBatis 动态 SQL。
<select id="pageReport" resultType="map"> select id, report_no, address, type, status, create_time from fire_report <where> <if test="status != null"> and status = #{status} </if> <if test="keyword != null and keyword != ''"> and address like concat('%', #{keyword}, '%') </if> </where> order by create_time desc limit #{offset}, #{pageSize} </select><where>标签会自动处理第一个条件前面的and，不传条件时生成不带 where 的查询。limit #{offset}, #{pageSize}是 MySQL 的分页写法，换成 SQL Server 就要用offset fetch。如果数据量上来，深分页会越来越慢，常见做法是改成基于游标的分页，也就是记住上一页最后一条记录的id或create_time。读过 MyBatis 源码的话应该记得MapperProxy会为每个 mapper 接口生成代理对象，这里的动态 SQL 最终是在DynamicSqlSource里解析拼装，理解这一层对排查慢 SQL 很有帮助。
2.3 审核状态字段：从提交到处理完成的状态流转
消防隐患举报不是一条数据写进去就结束，它要经历用户提交、后台审核、监管人员处理、用户评价几个阶段。大部分实现不会引入复杂状态机，而是用一个status字段配合更新时间来驱动。
| status | 含义 | 触发方 |
|---|---|---|
| 0 | 待审核 | 用户提交 |
| 1 | 审核通过 | 后台管理人员 |
| 2 | 审核拒绝 | 后台管理人员 |
| 3 | 处理中 | 消防监管人员 |
| 4 | 已完成 | 监管人员反馈处理结果 |
推荐的做法是把状态流转封装在 Service 层方法里，比如auditReport(id, status, opinion)、startHandle(id, handlerName)，而不是在 Controller 里直接 update 字段。这样做的原因是后续加权限、加通知时只需要改 Service，不用动接口。字段本身用TINYINT而不是VARCHAR，排序、统计都更快，也避免中文状态值带来的脏数据。
3. 数据库设计的五个核心表和初始化 SQL 里的坑
3.1 核心表结构：用户表、举报表、审核记录表、处理记录表、反馈表
很多数据库课程设计会卡在表关系上：举报信息审核通过后，处理记录应该挂在举报表还是单独建表？我的建议是分开。举报主表保持轻量，审核、处理、反馈都是独立的过程表，这样既能记录多次操作历史，又不会让fire_report表字段无限膨胀。
| 表名 | 关键字段 | 作用 |
|---|---|---|
| sys_user | id、openid、nickname、phone、role | 小程序用户和管理员 |
| fire_report | id、report_no、user_id、address、type、description、image_paths、status | 举报主表 |
| fire_audit | id、report_id、audit_user、opinion、create_time | 审核记录 |
| fire_handle | id、report_id、handler_name、handle_result、handle_time | 处理记录 |
| fire_feedback | id、report_id、score、comment、create_time | 用户反馈与评价 |
这里要特别注意openid字段。微信小程序登录后拿到的是用户唯一标识，不建议把openid当作自增主键的替代品，而是放在sys_user表里加唯一索引。举报表通过user_id关联用户，业务查询时用openid反查user_id，职责更清晰。
3.2 初始化 SQL 脚本中的 utf8mb4 与时间字段
项目中通常会附带一份fire_safety.sql初始化脚本。打开后先检查建表语句的字符集，消防隐患描述里可能出现生僻字或特殊符号，必须使用utf8mb4。
CREATE TABLE fire_report ( id BIGINT PRIMARY KEY AUTO_INCREMENT, report_no VARCHAR(32) NOT NULL COMMENT '举报单号', user_id BIGINT NOT NULL COMMENT '举报人ID', address VARCHAR(255) NOT NULL COMMENT '隐患地址', type TINYINT NOT NULL COMMENT '隐患类型：1-通道堵塞 2-设施损坏 3-违规用火 4-其他', description TEXT COMMENT '隐患描述', image_paths VARCHAR(1000) COMMENT '图片路径，逗号分隔', status TINYINT NOT NULL DEFAULT 0 COMMENT '状态：0待审核 1通过 2拒绝 3处理中 4完成', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_status_create (status, create_time) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这里把status和create_time建成联合索引，因为后台列表页最常用的查询就是按状态筛选并按时间倒序。image_paths用逗号分隔图片路径是常见做法，但它不适合做按图查询；如果后续要做图片单独管理，应该拆一张fire_report_image表。
3.3 Navicat 和命令行导入脚本时的常见报错
导入数据库脚本时不建议直接在 Navicat 里双击运行整个 SQL，常见做法是用命令行先确认目标库存在。
mysql -uroot -p fire_safety < fire_safety.sql如果脚本里已经有CREATE DATABASE和USE语句，前面的fire_safety参数可以去掉。导入过程中最常见的报错是Specified key was too long，这是因为VARCHAR(255)在utf8mb4字符集下索引长度超过 767 字节。MySQL 5.6 以下需要开启innodb_large_prefix，5.7 之后还要确认行格式是DYNAMIC或COMPRESSED。遇到问题先执行SHOW VARIABLES LIKE 'innodb_large_prefix';，再决定是改配置还是把索引字段长度缩短。
4. 微信小程序端：登录态、图片上传与抓包排错
4.1 先判断项目是原生小程序还是 uniapp
这套资源里出现了.vue.bak文件，很多人会误以为小程序端也是 Vue 写的。实际上.vue.bak一般出现在后台管理端，也就是运行在浏览器里的 Vue 项目。小程序端需要检查根目录下有没有app.json，有app.json的是原生微信小程序；如果根目录是pages.json加manifest.json，那是 uni-app 工程，可以用 HBuilderX 开发微信小程序。两种工程的页面文件后缀不同，原生是.wxml，uni-app 是.vue，调试时不要搞混。
4.2 登录态与 wx.request 会话保持
小程序端提交举报前必须先建立用户身份。最简单的方式是wx.login获取临时 code，传给后端，后端再调用微信接口换取 openid，并返回自定义 token。
wx.login({ success(res) { wx.request({ url: 'http://localhost:8080/api/user/login', method: 'POST', data: { code: res.code }, success(loginRes) { wx.setStorageSync('token', loginRes.data.data.token); } }); } });code有效期只有五分钟，且只能用一次，所以每次冷启动都要重新走一遍这个流程。后端拿到 code 后不能直接信任，要校验appid + secret的调用结果。实际项目里不会每一次页面加载都调wx.login，而是先读本地 token，失效时再去刷新。小程序端请求时把 token 放到 header 的Authorization字段，后端用拦截器统一解析。
4.3 图片上传：wx.chooseMedia 与 MultipartFile 的字段对应
举报信息里最容易被忽略的是多图上传。微信小程序没有直接传数组的接口，wx.uploadFile一次只能传一个文件，所以多图场景要循环调用。代码里name字段必须和后端@RequestParam("file") MultipartFile file保持一致，否则后端会一直报Required request part 'file' is not present。
wx.chooseMedia({ count: 3, mediaType: ['image'], success(res) { res.tempFiles.forEach(item => { wx.uploadFile({ url: 'http://localhost:8080/api/report/upload', filePath: item.tempFilePath, name: 'file', formData: { reportNo: 'XF' + Date.now() }, success(uploadRes) { console.log(uploadRes.data); } }); }); } });wx.chooseMedia是基础库 2.10.0 以后推荐使用的 API，替代了旧的wx.chooseImage。上传前可以在sizeType里指定压缩，减少流量消耗。后端接收后建议生成 UUID 文件名，不要直接使用用户提交的文件名，防止路径穿越和重名覆盖。
4.4 微信小程序抓包排错：先看 vConsole 再看网络面板
请求报 404 或 500 时，不要急着改代码。微信小程序抓包比其他 Web 项目多一层限制，对初学者来说最直接的办法是在开发者工具里打开「不校验合法域名」选项，这只适用于本地调试。真机预览时，在小程序右上角打开「开发调试」，页面上会直接出现 vConsole 浮层，里面能看到每个请求的地址、状态码、请求头和返回体。
排查顺序一般是这样：先在 vConsole 里看 status code，404 看后端路由和小程序请求路径是否一致；405 看请求方法，后端@PostMapping对应小程序method: 'POST'；500 看后端控制台堆栈，重点检查 JSON 字段名是否匹配。如果后端接口已经被浏览器验证过，小程序端却不通，优先检查域名配置和 HTTPS 证书，而不是怀疑后端逻辑。
5. 从脚本启动到 curl 闭环：一套可复现的验证清单
5.1 三个批处理脚本的执行顺序
项目里带有1-install.bat、2-run.bat、3-build.bat，从命名就能看出这是按阶段拆分的脚本。执行顺序是安装依赖、启动后端、构建前端。启动前先确认本地 JDK、Maven、MySQL 版本，SSM 项目在 JDK 8 下运行比较稳妥，MySQL 5.7 或 8.0 都可以。如果2-run.bat启动后端口被占用，先netstat -ano | findstr 8080找到进程，再决定改端口还是清进程。
5.2 用 curl 模拟举报后台上审核闭环
小程序不方便自动化验证时，用 curl 可以快速走通后端流程。先登录拿 token，再提交举报，最后审核。
curl -X POST http://localhost:8080/api/user/login \ -H "Content-Type: application/json" \ -d '{"username":"admin","password":"123456"}'拿到返回的 token 后，追加到审核请求的 header 中。
curl -X POST http://localhost:8080/api/report/audit \ -H "Content-Type: application/json" \ -H "Authorization: Bearer <token>" \ -d '{"reportId":1,"status":1,"opinion":"现场已核实"}'验证通过后用列表接口确认状态变化。
curl "http://localhost:8080/api/report/list?status=1&page=1&pageSize=10"如果列表返回的status已经变成 1，说明审核闭环打通。这一步比直接在页面上点按钮更高效，也方便写进课程设计报告作为功能测试证据。
5.3 答辩前值得补的三处细节
第一，在论文里把fire_report.status的状态流转画成表格，说明为什么用数字而不是字符串。第二，指出动态 SQL 对字段注入的防护，强调#{}占位符。第三，补充重复举报的处理策略，常见做法是提交时先按address和type查最近记录，同一地址同一类型且未完成处置时给出提示。建议把type字段整理为单独字典表，并在后台管理界面里做成可配置的下拉项，这样答辩时被问到扩展性会更有底气。
本文还有配套的精品资源，点击获取
