做毕设选“基于Spring Boot的智慧工厂安全生产监督管理系统”这个题目的同学，最近几年越来越多。每次一聊到这个题目，我的第一反应就是：这是一个典型的“看着容易、做起来杂”的管理系统。它不像算法题那样需要烧脑，但涉及的模块多、角色多、状态流转多，真正把需求理清并做完的学生，往往能在答辩里拿下一个不错的成绩；而只是把前后端拼在一起、能跑通主流程就交差的，很容易被几个追问顶到墙角。我会把选题定位、技术方案、核心模块实现、常见坑点、答辩准备全部分享出来，给正在做类似项目的同学一个参考。
这个系统解决的核心问题很明确：工厂里安全生产不能靠口头管理，需要有迹可循、有权有责、有预警有闭环。智慧工厂安全生产监督管理系统一般会覆盖人员、设备、环境、隐患、巡检、报警等维度，配合实时监测和统计分析，把安全管理工作从“纸质台账”搬到“线上流程”。Spring Boot作为后端基础框架，是目前Java毕设里最主流的选择，上手成本低、生态成熟、社区资料多，而且同样一套技术栈在工作后也能直接用，选它作为技术底座，既稳又不掉价。
1. 项目整体定位与核心需求拆解
1.1 智慧工厂安全系统到底是做什么的
很多同学一开始会把这类系统理解成“一个带增删改查的网页”，但答辩老师真正关注的是你有没有搞清楚业务场景。智慧工厂安全生产监督管理系统，本质上是一个面向工厂内部安全管理部门的信息化工具，通常服务于三类核心角色：企业安全管理员、车间巡检人员、分管领导（或者决策层）。不同角色对系统的诉求完全不一样，这决定了权限设计和功能菜单不能是拍脑袋的。
巡检人员要的是“少打字、快上报”——到了巡检点，扫码或者选择区域，按模板填写检查项，发现隐患直接拍照上传，后续整改任务自动派发。安全管理员要的是“能闭环、能追溯”——每一条隐患从发现、评估、指派、整改到复查验收，全程有状态、有责任人、有时间节点，出了事能倒查。领导层要的是“一张图看全局”——今天有多少隐患未整改、哪些设备报警了、各车间风险等级如何，不需要翻Excel表，打开大屏就能看到。
所以这个系统的核心需求可以拆成四大块：基础数据管理、隐患排查治理、安全巡检、实时监测预警。基础数据管的是组织架构、人员信息、设备台账、风险点清单；隐患管理管的是发现到销号的完整流程；巡检管理管的是计划和执行记录；实时监测管的是接入手持终端或传感器的数据，达到阈值触发报警。四个模块不是孤立的，隐患可能来自巡检，也可能来自监测报警，最终都会汇入统计分析。
1.2 为什么这个题目适合作为毕业设计
“适合”不等于“简单”，而是投入产出比高。从技术角度看，它覆盖了Spring Boot、MyBatis/MyBatis-Plus、MySQL、Vue等主流技术，还有权限控制、文件上传、WebSocket实时通信、定时任务、报表统计这些高频知识点，几乎每一项都能在简历上写一笔。从业务角度看，工厂安全是近几年政策关注的重点领域，选题有一定现实意义，答辩时不用担心“做这个有什么用”被问倒。
更重要的是，这个题目有清晰的“递进逻辑”。你可以做一个基础版：用户登录、角色权限、隐患登记与整改列表、简单统计；也可以往深度扩展：对接模拟传感器数据、用WebSocket实时推送报警、生成车间安全态势大屏。这种扩展性让不同能力水平的同学都能找到自己的定位，也方便在说明文档里写“后续可扩展方向”。从我接触到的实际情况看，大部分选择这个题目的同学，最后拿到的评价往往取决于是否把“闭环”做完整，而不是功能数量有多少。
1.3 需求清单与模块边界划分
在动手写代码之前，先把模块边界划清楚，能少走很多弯路。我习惯用一个简化的需求清单来做规划，列在这里供参考：
| 模块 | 主要功能点 | 目标角色 |
|---|---|---|
| 系统管理 | 用户管理、角色管理、菜单权限、日志管理 | 系统管理员 |
| 基础档案 | 部门/车间管理、岗位管理、设备台账、风险点管理 | 安全管理员 |
| 隐患管理 | 隐患上报、隐患审核、整改指派、整改反馈、复查销号 | 巡检人员/安全管理员 |
| 巡检管理 | 巡检计划、巡检任务、巡检记录、异常处理 | 巡检人员 |
| 实时监测 | 监测点管理、实时数据接入、阈值报警、报警处理 | 安全管理员/领导 |
| 统计报表 | 隐患统计、巡检完成率、设备报警排名、安全态势图 | 领导/安全管理员 |
| 公告通知 | 安全通知发布、待办事项提醒 | 全员 |
第一次做这类系统，切忌一上来就建几十张表。建议先做核心四表：用户表、角色表、隐患表、巡检记录表。先把基础流程跑通，再逐步加设备、预警、统计。很多人就是前期表设计太复杂，导致后期改来改去，最后bug一堆。
2. 核心技术选型与架构设计
2.1 后端技术栈：Spring Boot是稳妥的底座
后端选择Spring Boot 2.x或3.x都可以，但从毕设兼容性考虑，Spring Boot 2.7.x加JDK 8或11最省心，到了Spring Boot 3.x需要JDK 17起步，部分实验室旧电脑环境可能不完全兼容。Spring Boot的优势不用多介绍，自动配置、开箱即用、独立部署，配合Maven管理依赖，对一个单体管理系统来说是再合适不过的选择。
持久层方面，我优先推荐MyBatis-Plus，而不是原生MyBatis。原因是MyBatis-Plus提供了BaseMapper，单表CRUD几乎不用写SQL，代码量直接砍掉三分之一；分页插件也有了现成的分页查询；唯一的“教学风险”是学生容易过度依赖封装，复杂多表查询还是要自己写SQL。如果你希望答辩时能清晰回答MyBatis的#{}和${}区别，建议在关键模块保留几段手写SQL，并且自己注释好，这也是加分项。
安全认证方面，可以选择Spring Security或Shiro。我更推荐Shiro，因为它的权限模型简单直观，Realm、Subject、SecurityManager这套概念在毕设里足够用。JWT在前后端分离项目中几乎是标配，把登录成功生成的Token放在请求头里，后端拦截器或过滤器统一校验，就能实现无状态认证。
2.2 前端方案：Vue + Element UI 是主流组合
前端如果完全手写，工作量会非常大。现在的毕设项目基本都会用Vue 2 + Element UI，或者Vue 3 + Element Plus。Vue 2的技术资料多、Element UI组件丰富，适合第一次做前端项目的同学；Vue 3组合式API更现代，但相关的坑也相对多一些。我个人建议：如果目标是快速出成果、把时间花在业务逻辑上，选择Vue 2 + Element UI + axios + ECharts这个黄金组合。
ECharts是数据可视化绕不开的工具，用它做饼图、柱状图、折线图都很方便。统计报表模块里，隐患分类占比、各车间隐患数量、近一个月报警趋势，三个图表基本就能撑起领导看板。这里有一个技巧：不要在前端写死数据，把统计接口返回的JSON结构设计好，前端直接setOption，这样后期替换真实数据不用改代码。
前端路由和菜单权限也需要联动。登录成功后，后端返回该用户可见的菜单列表，前端动态添加路由；按钮级别的权限则通过自定义指令或v-if判断。Vue Router的动态添加路由方法在Vue 2里使用router.addRoutes，Vue 3里变成了router.addRoute，很多同学在这上面踩过坑。建议在项目开始时就把菜单权限和路由守卫的代码统一封装好，避免后续手工改菜单。
2.3 数据库设计与关键表关系
数据库设计是整个系统的地基，也是很多同学在最初阶段最容易忽视的部分。表设计得好不好，直接决定后面写SQL的复杂度，以及后期加功能时是否需要反复改动结构。我在给这个项目做整体规划时，没有一上来就建二十多张表，而是先把核心业务场景中必然会涉及的几张主表列出来，按照“用户—角色—权限—业务数据—流程记录”这条线索逐层展开，再在实现过程中根据实际需要补充从表。这样做的好处是，前期不至于被繁杂的字段拖住，后期出现需求变化时，调整成本也可控。下面以一个常见的简化版本说明这个系统的核心表结构。
用户表包含用户ID、用户名、密码、姓名、手机号、部门ID、状态等字段；角色表包含角色ID、角色名、角色编码；用户角色关联表负责多对多关系；菜单表包含菜单ID、父菜单ID、菜单名、路由地址、权限标识；角色菜单关联表则控制菜单可见性。数据库里建议使用逻辑删除字段deleted，并在所有查询中统一带上deleted=0的条件，这样可以避免用户误删数据后不可恢复。唯一需要注意的是，MyBatis-Plus的逻辑删除全局配置要配好，否则直接执行自定义SQL时不会自动过滤已删除数据。
隐患表是这个系统里业务状态最复杂的表。字段至少包括隐患ID、隐患编号、发现时间、发现人、隐患类型、风险等级、隐患描述、附件URL、所属区域、状态（待审核/待整改/整改中/待复查/已销号）、当前处理人、整改期限、整改措施、复查结论等。看起来字段多，但每一个都有明确用途，尤其是状态字段，所有流程跳转都依赖它。为了方便不同角色查询，建议在隐患表上加上create_dept_id字段，用来做数据权限的过滤条件。
设备表和监测点表建议分开。设备表维护设备的基本信息，包括设备编号、名称、类型、安装位置、责任人、投用日期、状态；监测点表则维护具体监测指标，例如温度、压力、粉尘浓度、噪声等，每个监测点绑定一台设备和一个预警阈值。这样设计的好处是，一台设备可以对应多个监测点，后续扩展传感器也不至于改表结构。两张表通过device_id关联，报警记录表则记录监测点ID、报警值、报警时间、处理状态和处理人。
3. 核心模块从0到1实现
3.1 基于RBAC的权限控制实现
权限控制是管理系统的第一道门，同时也是很多同学容易搞混的地方。我建议采用RBAC模型：用户关联角色，角色关联菜单和权限标识。后端接口通过注解或代码判断当前用户是否有某个权限标识，例如@RequiresPermissions("hidden:delete")，前端则根据登录用户的菜单列表动态生成路由。
登录流程上，用户的用户名、密码提交后，后端先通过subject.login(token)完成认证，成功后从数据库查出该用户的所有角色和权限，生成JWT，同时把权限集合缓存到Redis。后续每次请求都携带JWT，拦截器里解析用户ID，再从缓存中加载权限。如果不想引入Redis，也可以把权限信息放入ThreadLocal，每次请求查库，缺点是部分压力集中在数据库，但毕设规模完全够用。
这里要特别注意一个细节：菜单权限和数据权限是两个不同的层级。菜单权限控制的是“能否看到这个按钮”，数据权限控制的是“能看到哪些部门或哪些人的数据”。比如车间主任登录后，只能看到本车间的隐患记录，这就是数据权限。实现数据权限的一个简单方案是在业务查询Mapper中加入dept_id过滤条件，根据当前用户的部门编码动态拼接。答辩时如果能主动讲清“菜单权限和数据权限的区别”，通常是明显的加分项。
3.2 隐患管理：状态机设计与流程闭环
隐患管理做得好的系统，答辩时能明显加分。隐患的典型状态流转是：待审核 — 待整改 — 整改中 — 待复查 — 已销号。任何一个环节都有对应的角色去操作。用一张状态图描述很直观，但在代码里我习惯用常量或枚举约束状态，而不是到处写魔法数字。
隐患上报的前端页面，需要支持选择隐患类型、区域位置、风险等级（一般/较大/重大）、上传现场照片。后端在保存时自动生成隐患编号，格式可以用“YH+年月日+四位流水号”，例如YH202506230001。生成编号的逻辑放在事务里，避免并发重复。隐患审核时，审核人可以驳回，驳回后需要填写驳回原因，回到上报人员处修改重新提交。
整改指派是整个流程里最需要考虑细节的部分。整改责任人和整改期限是必填的；如果超过期限未完成，系统应该自动给安全管理员发送待办提醒。我实现的时候，定义了一个定时任务，每天凌晨扫描所有状态为“整改中”且整改期限小于当前时间的隐患记录，插入提醒通知表。这个功能并不难，但做出来后显得系统很“聪明”。隐患销号前，还需要进行复查，复查结论要填写“通过”或“不通过”，不通过时需要重新进入整改流程。这种状态回退逻辑如果不提前想清楚，代码会写得很乱。
3.3 巡检模块：计划生成与执行轨迹
巡检模块涉及的逻辑相对直接：管理员创建巡检计划，选择巡检区域、巡检项模板、执行人、开始和截止时间；到点后，执行人微信或Web端收到待办，进入巡检页面按清单逐项确认；每一项可选择正常/异常，异常时需要填写说明并上传照片；最后点击提交，生成一张巡检记录单。
这里的一个关键点是巡检模板设计。巡检项模板可以单独建一张表，包含模板名称、检查项名称、检查标准、是否必填。巡检计划关联某个模板，执行人看到的检查项就是模板实例化的结果。比如“配电房巡检模板”包含“电压是否正常”“温度是否超标”“消防器材是否齐全”三个检查项；而“车间通道巡检模板”则包含“安全通道有无堆放杂物”“应急照明是否正常”等。这样设计，同一个巡检模块就能适配不同类型的场景。
巡检记录在保存时，除了记录每个检查项的结果，还应该记录整体结论（通过/不通过）和签字人员。如果实际开发中实现电子签名比较麻烦，可以用登录用户名加时间戳代替，答辩时说明是一种简化方案即可。巡检记录的查询页面要有按计划、按执行人、按时间范围筛选的功能，方便安全管理员回头看某一车间的历史巡检情况。这里我建议在巡检记录表上建一个联合索引(plan_id, execute_user, check_time)，否则数据量稍微一多，查询就会变得很慢。
3.4 实时监测与报警推送
实时监测模块是智慧工厂场景里最有“科技感”的部分。真实环境下，现场设备通过Modbus、OPC UA等协议把数据传输到网关，再写入消息队列或数据库；但毕设项目一般不会真的对接硬件设备，所以更多是模拟数据。常规做法是写一个后台定时任务，每5秒向监测记录表插入一条模拟数据，数值围绕基准值随机波动，当超过阈值时触发报警。
前端展示可以使用WebSocket建立长连接，后端把新的监测数据或报警事件推送到页面。Spring Boot中实现WebSocket的方式很多，最简单的就是使用spring-boot-starter-websocket，注册一个TextWebSocketHandler。每产生一条新报警，后端通过SimpMessagingTemplate或者自己维护的Session列表广播给指定前端页面。这里要说一个坑：WebSocket在多实例部署时会因为Session不在同一台机器上而无法推送，不过毕设是单机部署，所以不用太担心。
报警处理流程也要有闭环：报警记录生成后，系统自动给对应区域的安全负责人生成一条待处理任务；负责人到现场确认后填写处理措施，报警状态从未处理变为已处理。如果不做这个闭环，报警就只是一个闪烁的红点，缺少实际意义。模拟数据生成器建议做成可配置的开关，比如系统设置里有一个“是否启用实时数据模拟”的配置项，演示的时候打开，平时调试可以关闭，不然开发环境里日志会被刷屏。
3.5 统计报表与安全态势大屏
统计报表是给领导看的，也是答辩时的“门面”。建议用ECharts实现三类图表：一是隐患分类饼图，展示各类隐患数量占比；二是各车间隐患数量柱状图，方便横向比较；三是近30天报警趋势折线图。还可以做一张“安全态势大屏”，把核心指标（今日新增隐患、待整改隐患数、本月巡检完成率、设备报警总数）用四个大数字卡片展示。
大屏的设计原则是信息密度适中。不要堆砌太多图，尽量围绕“安全状态”这个核心来组织。我见过不少同学把大屏做成了花里胡哨的动态背景，动效一堆但核心数据看不清，反而被老师批评。更稳妥的做法是把数字放大、配色统一、布局干净，再配上简单的自动刷新。自动刷新可以用前端定时器每隔30秒重新请求一次统计数据，也可以用WebSocket实时推送整体概览数据。如果图表数据接口设计得好，大屏页面的代码其实非常简单。
4. 实操过程中的常见坑与排查技巧
4.1 前后端联调必遇到的跨域问题
前后端分离模式下，跨域几乎是第一道坎。后端接口地址是http://localhost:8080，前端开发服务器是http://localhost:8081，浏览器默认会拦截跨域请求。解决方式有几种：在后端写一个CorsConfig配置类，设置允许的源、头信息、方法；或者在控制器上加@CrossOrigin注解；也可以使用代理方式，前端Vue配置文件里的proxy把/api开头的请求转发到后端。
我个人推荐第一种全局配置，因为一劳永逸，不用每个接口都加注解。配置时要特别注意allowedOriginPatterns参数，Spring Boot 2.4以后不能直接使用allowedOrigins("*")配合allowCredentials(true)，否则启动时会报错。这个问题出现频率很高，很多同学卡了半天其实是版本差异导致的。正确的配置大致是设置allowedOriginPatterns("*")并在前端请求中携带withCredentials标志。同时，自定义拦截器里也要放行OPTIONS预检请求，否则跨域请求会在拦截器阶段就被拦下来，前端看到的错误是404而不是跨域错误，排查起来很容易走偏。
4.2 MyBatis动态SQL和查询条件拼接
多条件组合查询是管理系统的标配，比如隐患列表需要按时间范围、隐患类型、风险等级、处理状态等条件筛选。用MyBatis的<if>标签来动态拼接WHERE条件是最常见的做法，但这里有几个容易踩的坑。
第一，字段判断要用实体类属性名，不要误写成数据库列名；第二，数值类型参数判断时要注意0值会被当成非空但条件失效；第三，如果使用了MyBatis-Plus的QueryWrapper，要注意like方法的参数顺序是column在前、value在后。写复杂统计SQL时，建议先在数据库客户端里跑通，再粘到Mapper XML里；同时要注意SQL注释不能有中文字符括号不匹配，否则运行时不报错但结果异常。
另一个常见问题是${}和#{}的误用。${}是字符串拼接，存在SQL注入风险，一般只用来动态传入表名或排序字段。把用户输入的值用${}拼接，在答辩现场演示时被老师输入一个单引号，整个查询就会报错，场面会很尴尬。排序字段可以考虑用白名单校验，比如只允许传入后端定义好的列名，而不是直接把前端传来的字符串拼进ORDER BY。
4.3 日期时间处理与前后端时区问题
Java后端返回日期给前端时，如果不做统一处理，经常会出现“后台是Date，前端显示一串时间戳”的问题。一个常见的做法是在application.yml中配置日期格式和时区：
spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8如果项目返回的是LocalDateTime类型，还需要引入jsr310的依赖或单独配置JavaTimeModule。另一个容易忽略的点是前端提交日期字符串时，后端接收需要指定格式。一般用@DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss")或直接在实体字段上设置JsonFormat注解。总的来说，日期问题最好在设计实体时就把字段类型和前后端格式约定好，避免临时到处改。
如果使用默认的Date类型，还需要注意数据库驱动和数据库时区不一致会导致查询结果差8小时。例如MySQL连接串里加上serverTimezone=Asia/Shanghai，Spring Boot的高版本驱动一般会自动识别，但最好还是显式指定。答辩时如果被问到“为什么有的系统显示的时间差8个小时”，你如果能答出时区问题，说明你真的调过Bug。
4.4 权限注解失效与Token过期处理
很多同学把Shiro或者Spring Security配好后，发现接口上加了权限注解并没有生效，原因往往是没有启用注解驱动。Shiro需要配置DefaultAdvisorAutoProxyCreator和AuthorizationAttributeSourceAdvisor；Spring Security需要在配置类上加@EnableGlobalMethodSecurity。如果用的是JWT，还要确认自定义拦截器和权限注解不是互相替代的关系，而是配合工作。
Token过期则是一个前端体验问题。当后端返回401时，前端axios拦截器应该统一处理，清除本地登录信息并跳转到登录页。不要只在某个页面处理，否则用户会在半个系统里到处看到空白页。这里可以加一个提示：“登录状态已过期，请重新登录”，比直接跳转体验好一些。
权限注解还有一个容易出问题的点：注解写在Controller上，但实际业务中同样一个方法可能被多个角色调用。比如隐患列表接口，巡检人员要能看到自己上报的隐患，安全管理员要能看到全部隐患，部门领导要能看到本部门隐患。如果只用一个@RequiresPermissions注解，无法表达这种数据范围差异。解决方法是接口不做权限限制，而是在Service里根据当前用户角色动态拼接查询条件，或者自定义数据权限注解，在Service层拦截处理。
4.5 WebSocket连接经常断开或数据不实时
WebSocket看似简单，实际环境中会遇到连接经常断开的情况。常见原因有：前端没有处理心跳，服务器或代理的超时时间到了之后主动断开；后端发送消息频率过高，页面渲染卡顿；浏览器对并发连接数有限制。解决方法是：前端每隔一段时间发送一个ping消息，后端收到后返回pong；如果超过一定时间没收到pong，前端重连。后端推送消息时，可以适当合并数据，不要每次更新都推全量列表，只推增量数据。
在使用Spring Boot原生WebSocket时，TextWebSocketHandler的afterConnectionEstablished方法里会保存Session对象到本地ConcurrentHashMap。要注意，客户端断开连接时，afterConnectionClosed方法必须移除对应的Session，否则会越积越多，最终内存溢出。另外，后端主动发送消息时，需要先判断Session是否仍然有效，session.isOpen()为false则不能调用sendMessage。这些细节在压力测试或者频繁刷新页面时就会暴露出来。
5. 部署发布与毕设答辩要点
5.1 项目打包与部署运行
后端项目是Spring Boot的Maven工程，打包时执行mvn clean package，会生成一个可执行的Jar包。默认情况下Spring Boot内嵌了Tomcat，所以部署时不需要单独的Tomcat环境，只要服务器有JDK就可以。我在给同学解决问题时发现，最容易出错的是打包后运行找不到配置文件，或者Jar包内没有包含静态资源。解决办法是确认pom.xml中build配置的finalName是否正常，以及resources目录是否被包含到classpath。
前端项目构建时执行npm run build，生成dist目录。如果不想额外部署Nginx，可以直接把dist目录里的静态文件复制到Spring Boot项目下的src/main/resources/static中，然后重新打包，前后端就合并成一个Jar包了。这个做法适合毕设演示，一个Jar包跑起来就能看到完整页面，非常省事。运行命令是java -jar xxx.jar，注意确认JDK版本和打包时一致，否则会报UnsupportedClassVersionError。
5.2 演示数据准备与重点场景演练
答辩演示不是打开系统随便点两下，而是要有剧本地去演示关键场景。我建议在答辩前准备好一套完整演示数据：一个超级管理员账号、一个车间主任账号、一个巡检员账号，每个账号对应不同角色和可见数据范围。演示时先管理员登录，展示权限菜单和用户管理；再切到巡检员，执行一次巡检并上报一条隐患；然后切回安全管理员，审核隐患、指派整改；最后到领导看板页，展示统计图表和报警处理记录。
答辩老师最喜欢问的问题是：“这条隐患从上报到销号，整个流程中各角色分别做了什么？”所以你自己一定要能流畅说出这个流程。关键技术问题也会围绕权限控制、数据库表设计、实时报警实现方式展开。提前准备一份核心表结构的说明，画几个简单的表关系图放在PPT里，会显得你确实动了脑子。我见过不少同学在演示到“实时报警”时，因为模拟数据没有启动而页面空白，所以答辩前一定要检查模拟数据开关是打开的，并且前端能正常收到推送。
5.3 说明文档（LW）与项目源码组织
说明文档是毕设评分的重要组成部分。不要把它当成流水账，建议采用“问题驱动”的结构：先提出工厂安全生产管理过程中的具体问题，再说明系统如何通过信息化手段解决这些问题。重点章节可以包括需求分析、系统设计、数据库设计、核心功能实现、系统测试。在系统测试部分，除了写功能测试表，最好加上几个有说头的用例，例如“并发用户同时上报隐患”和“超过整改期限的自动提醒验证”，听起来更有说服力。
源码组织方面，命名规范要统一。后端按controller、service、mapper、entity、common、config分层，前端按views、components、api、router、utils组织。不要把所有页面堆到同一个目录下，那样代码评审不过关。项目里尽量加上简单的注释，尤其是核心业务逻辑，不用写太多，但至少让阅读者能明白每个方法在做什么。数据库初始化脚本一定要放在项目目录的sql文件夹下，并且附上测试数据。答辩老师如果拿到项目源码，通常会直接去找建表语句和README，如果这些都没有，印象分会低不少。
5.4 我个人的一些建议
做这类系统，最忌讳贪多求全。在你还没把核心闭环跑通之前，不要花大量时间去做系统通知、操作日志、皮肤切换这类锦上添花的功能。先把用户、角色、隐患、巡检、统计这条主线走通，然后把所有影响演示的功能都打磨一遍，最后再考虑扩展。如果你时间充裕，可以加一个“一键生成巡检报告PDF”的功能，或者把数据模拟模块做成可配置的开关，这些在答辩时都会成为亮点。
另外，一定要重视代码提交记录。哪怕是自己一个人做，也建议用Git管理项目，每完成一个模块就提交一次。这不光是好习惯，遇到代码改乱时能快速回滚，而且在说明文档的“开发过程管理”部分还能写一笔，显得项目过程规范。
根据我的经验，选择这类SSM/Spring Boot管理系统的同学，最大的通病不是写不出代码，而是“不知道自己做了什么”。项目做完后，一定要能脱离IDE，用嘴巴把系统的架构、数据流向、核心流程讲清楚。能做到这一点，答辩基本就稳了。
