简介一套微信小程序消防隐患在线举报系统是针对消防隐患网络举报场景的完整毕业设计资源适合高校学生用于课程设计、毕业设计或项目实战练习。系统基于SSMSpring、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 idpageReport resultTypemap select id, report_no, address, type, status, create_time from fire_report where if teststatus ! null and status #{status} /if if testkeyword ! null and keyword ! and address like concat(%, #{keyword}, %) /if /where order by create_time desc limit #{offset}, #{pageSize} /selectwhere标签会自动处理第一个条件前面的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_userid、openid、nickname、phone、role小程序用户和管理员fire_reportid、report_no、user_id、address、type、description、image_paths、status举报主表fire_auditid、report_id、audit_user、opinion、create_time审核记录fire_handleid、report_id、handler_name、handle_result、handle_time处理记录fire_feedbackid、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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里把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_prefix5.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 开发微信小程序。两种工程的页面文件后缀不同原生是.wxmluni-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 code404 看后端路由和小程序请求路径是否一致405 看请求方法后端PostMapping对应小程序method: POST500 看后端控制台堆栈重点检查 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?status1page1pageSize10如果列表返回的status已经变成 1说明审核闭环打通。这一步比直接在页面上点按钮更高效也方便写进课程设计报告作为功能测试证据。5.3 答辩前值得补的三处细节第一在论文里把fire_report.status的状态流转画成表格说明为什么用数字而不是字符串。第二指出动态 SQL 对字段注入的防护强调#{}占位符。第三补充重复举报的处理策略常见做法是提交时先按address和type查最近记录同一地址同一类型且未完成处置时给出提示。建议把type字段整理为单独字典表并在后台管理界面里做成可配置的下拉项这样答辩时被问到扩展性会更有底气。本文还有配套的精品资源点击获取 微信小程序消防隐患举报系统：SSM后端与数据库设计实践
简介一套微信小程序消防隐患在线举报系统是针对消防隐患网络举报场景的完整毕业设计资源适合高校学生用于课程设计、毕业设计或项目实战练习。系统基于SSMSpring、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 idpageReport resultTypemap select id, report_no, address, type, status, create_time from fire_report where if teststatus ! null and status #{status} /if if testkeyword ! null and keyword ! and address like concat(%, #{keyword}, %) /if /where order by create_time desc limit #{offset}, #{pageSize} /selectwhere标签会自动处理第一个条件前面的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_userid、openid、nickname、phone、role小程序用户和管理员fire_reportid、report_no、user_id、address、type、description、image_paths、status举报主表fire_auditid、report_id、audit_user、opinion、create_time审核记录fire_handleid、report_id、handler_name、handle_result、handle_time处理记录fire_feedbackid、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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里把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_prefix5.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 开发微信小程序。两种工程的页面文件后缀不同原生是.wxmluni-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 code404 看后端路由和小程序请求路径是否一致405 看请求方法后端PostMapping对应小程序method: POST500 看后端控制台堆栈重点检查 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?status1page1pageSize10如果列表返回的status已经变成 1说明审核闭环打通。这一步比直接在页面上点按钮更高效也方便写进课程设计报告作为功能测试证据。5.3 答辩前值得补的三处细节第一在论文里把fire_report.status的状态流转画成表格说明为什么用数字而不是字符串。第二指出动态 SQL 对字段注入的防护强调#{}占位符。第三补充重复举报的处理策略常见做法是提交时先按address和type查最近记录同一地址同一类型且未完成处置时给出提示。建议把type字段整理为单独字典表并在后台管理界面里做成可配置的下拉项这样答辩时被问到扩展性会更有底气。本文还有配套的精品资源点击获取