1. 开工前先搞清楚这套EHS系统到底解决什么问题做毕业设计时最忌讳一上来就写代码。我见过太多同学拿到安全环保管理系统这类题目直接建个表就开始堆CRUD最后做出来的东西自己都讲不清楚业务逻辑答辩时被老师一问就卡壳。先说结论EHS是Environment环境、Health健康、Safety安全三个单词的缩写在制造型企业里这三件事往往由一个部门统管。EHS管理系统要解决的是企业安全管理中台账混乱、整改滞后、数据孤岛这三大顽疾。打个比方你就明白了。传统的安全巡检靠纸质检查表车间发现一处隐患填表、上报、等领导签字、再安排人去整改这个流程走下来少说三五天中间还容易丢单。环境部门要统计废弃物处置记录得翻几个月前的Excel。职业健康那边员工体检报告、劳保用品领用记录都散在各处想查某个班组近三年的体检异常情况几乎是不可能完成的任务。这套系统就是把安全、环境、健康三块数据统一收口到一个平台里。隐患可以从发现、上报、整改到复查全程线上流转环保数据可以形成可视化报表员工健康档案和劳保用品可以按人归档、到期提醒。对于毕业设计来说这题目的好处是领域特征强、功能边界清晰、业务逻辑足够复杂又不至于失控——既有常规的增删改查又有状态流转、审批、提醒这些有技术含量的设计点非常适合用来展示SpringBoot的核心能力。我带的几个学生做完这套系统后反馈很一致写业务代码本身难度不大真正花时间的反而是把EHS的业务规则理清楚以及把SpringBoot的周边生态权限、定时任务、文件存储、报表导出整合好。这篇就把整个思路铺开讲一遍重点会说我的设计取舍和踩坑过程可以直接拿来当开题和开发的参考。2. SpringBoot技术栈选型为什么是这个组合以及版本怎么定技术选型这块直接看我在实践中的取舍和理由。2.1 框架版本选2.7而不是3.x很多同学习惯把Spring Boot版本拉最新但做毕设我强烈建议用Spring Boot 2.7.x。原因很实际3.x基于Jakarta EE很多老教程里的javax包路径写法会报错排查起来费时间2.7是2.x系列最后一个免费维护版本资料最全遇到报错一搜就有答案大部分毕业设计的依赖比如MyBatis Plus、Shiro、JWT工具包在2.7下都有成熟兼容版本我用的是Spring Boot 2.7.8配合JDK 1.8。别小看JDK版本JDK 17配合2.7.x虽然也能跑但某些依赖会出现编译问题为了省事JDK 8是最稳妥的选择。2.2 核心依赖清单这套系统的依赖选型如下组件选型说明持久层MyBatis Plus 3.5.x内置分页插件和代码生成器省掉大量Mapper XML数据库MySQL 8.0开源、免费、毕设友好权限认证JWT Spring Security前后端分离项目的标准方案缓存Redis存登录态、验证码、高频读取的配置项文件存储MinIO统一种安全隐患图片、报告附件的上传管理定时任务Spring Quartz处理隐患超期提醒、劳保用品到期提醒报表导出Apache POI / EasyExcel生成Excel格式的统计报表这套组合的合理性在于每个组件都有明确的落地场景不会让人觉得为了用而用。比如Redis不只用来存登录状态还可以缓存隐患类型字典表这个设计在答辩时能体现你对性能的思考。2.3 Maven项目结构项目用Maven构建标准的父子模块结构ehs-system ├── ehs-common # 通用工具类、返回结果封装、异常处理 ├── ehs-framework # Spring Security、JWT过滤器、配置类 ├── ehs-system # 业务模块用户、角色、菜单 ├── ehs-domain # EHS业务实体和Mapper └── ehs-web # Controller层、启动类、配置文件如果是单体毕设用单模块其实也行但多模块有一个好处后端的代码量看起来更规范论文里画项目结构图也更有说服力。我实际开发中遇到过一个问题——Spring Boot Test扫描模块时Bean找不到后来发现是SpringBootApplication放在ehs-web模块而MyBatis的Mapper接口在ehs-domain模块需要指定ComponentScan和MapperScan的扫描路径这个细节很多人会踩。3. EHS核心数据模型安全、环境、健康三块业务怎么建表EHS系统的数据建模和普通业务系统不太一样它不是简单的用户-角色-菜单加几张业务表就完事。安全、环境、健康三块业务的数据关系既有独立维度又有交叉关联设计不好后面写SQL会非常痛苦。3.1 安全模块的核心表设计安全模块是整个EHS系统的重头戏最常见也最重要的两张表是隐患登记表和巡检任务表。隐患登记表的核心字段除了基础的主键、隐患描述、隐患位置、发现人、发现时间、风险等级还有一个关键字段叫隐患状态。我把它设计成状态机流转待整改 - 整改中 - 待复查 - 已闭环 ↑ ↓ 发现隐患 - 指派整改人 - 复查通过这个状态机是整个系统的核心逻辑之一。为什么我强调用状态机而不是单个状态字段因为隐患整改遵循的是**五定原则——定人员、定时间、定措施、定责任、定预案**。一张表只记录当前状态你就没法追溯这个隐患是谁指派的、整改期限是哪天、超期了系统要提醒谁。所以我在隐患表之外又加了一张整改进度日志表每条状态变更都落一条日志这样既能追责后续做报表也有原始数据。巡检任务表则是隐患的上游入口。我会预置一批巡检点比如一车间配电室仓库消火栓每个巡检点设置巡检周期和责任人定时任务到点自动生成巡检工单巡检人填写结果时如果发现问题一键转入隐患登记流程。这个联动设计是整个系统的演示亮点。3.2 环境模块与健康模块的表结构环境模块的表没有安全模块复杂但有一个容易忽略的点排放物的数据要按时间维度组织。我的设计中有一张废气排放记录表按月记录废气检测数据关联到对应的排放口和监测指标。展示时用折线图呈现趋势这张表就是图表的数据源。健康模块则是典型的一主多从结构。员工健康档案表做主表子表包括体检记录、劳保用品领用记录、职业危害接触记录。用员工ID关联后续可以一个员工页面把三年内的体检趋势、劳保领用明细都拉出来。EHS数据模型设计上最核心的一条经验是干线穷举优先建交叉统计靠中间表。比如查某车间在3月份有多少条隐患未闭环如果隐患表关联了车间ID一条SQL就解决如果当初没设计车间维度后面查这类统计只能逐条过滤性能堪忧。4. 隐患排查闭环流程状态机定时任务消息触达的落地细节安全隐患整改模块是这套系统里技术含量最高、也是答辩时最能拿出来讲的部分。这里把完整的设计链路拆开说。4.1 闭环流程的完整链路我设计的隐患闭环路径是这样的发现登记巡检人或任意登录用户填写隐患信息、上传现场照片、选择风险等级系统自动指派根据隐患所属区域自动匹配该区域的安全责任人生成整改任务整改处理责任人收到待办填写整改措施和整改结果复查验收安全主管对整改结果进行复查支持退回重改归档闭环复查通过后隐患单自动归档纳入历史台账在这个流程里SpringBoot的关键技术应用点有三个第一状态流转的后端实现。我写了一个整改状态处理器用策略模式加状态枚举来管理流转public enum RectificationStatus { PENDING(0, 待整改), PROCESSING(1, 整改中), PENDING_REVIEW(2, 待复查), CLOSED(3, 已闭环); private Integer code; private String desc; }每个状态下只允许执行特定的操作。比如已闭环状态不允许再提交整改内容Controller在入口做状态校验。这个设计比纯if-else判断要清晰得多也更好扩展。第二超时提醒的定时任务调度。隐患整改设置了整改期限一般高风险3天、中风险7天、低风险15天。我用Spring Quartz实现了一个跑批任务每天凌晨扫描隐患表把超过整改期限未关闭的隐患找出来向对应责任人推送待办通知。第三消息触达的渠道设计。系统内的待办信息通过站内信呈现——其实就是在数据库里加了一张通知表存接收人ID、内容、是否已读。用户登录后在首页的待办中心看到红点提醒。如果后续想扩展可以在这个基础上接邮件或短信接口可以做成策略模式。4.2 演示时的操作顺序怎么设计这里说一个答辩演示的小技巧。很多同学演示隐患模块时直接进列表页点新增填一条数据老师看着没有任何代入感。我的建议是先把一个预置的真实感场景放进去。比如提前录入一条带图片、有完整整改日志的隐患记录演示时从待办中心进入点开这条记录带着老师一步步看状态流转的历史轨迹。这样老师能直观感受到这个系统不是空壳是有真实业务承载的。我实测下来这条演示路线比生硬地演示增删改查效果好得多也更容易让老师理解系统的业务价值。5. 权限、缓存、文件上传、图表与报表通用能力怎么贴合EHS场景EHS系统的通用能力模块如果只是简单做登录注册和CRUD深度明显不够。这里讲几个我做了重点设计的地方。5.1 基于RBAC的多角色权限控制EHS平台的用户角色天然是多样化的系统管理员、安全主管、车间安全员、环境专员、职业健康专员、普通员工。不同角色看到的菜单和能操作的功能完全不一样。我用的方案是Spring Security JWT RBAC三张表用户、角色、菜单。登录成功后后端生成JWT令牌前端把令牌存到localStorage里每次请求在Header里带上。后端通过拦截器解析令牌把用户信息放进SecurityContext。权限控制的细化粒度我建议做到按钮级别。比如隐患登记按钮普通员工能看到但隐患指派按钮只有安全主管能操作。前端通过后端返回的按钮权限标识做v-if渲染后端在Controller增加PreAuthorize注解做二次校验。这个前端控制显示后端控制权限的双重校验是答辩时的一个加分项。5.2 Redis缓存的高频使用场景Redis在EHS系统里我主要用在了三个地方登录验证码生成后存Redis设置5分钟过期隐患类型字典启动时加载到Redis查询时优先走缓存用户待办数量登录后显示待办红点数字从Redis读取有变更时清除重建这里有一个缓存穿透的实际案例。隐患类型字典表总量不超过50条属于典型的读多写少数据。如果每次前端需要下拉框选项时都查数据库虽然压力不大但高频页面上接口响应会有明显延迟。我做了个简单处理接口先查Redis没有再从数据库加载并回写缓存。5.3 文件上传与MinIO整合隐患登记时要上传现场照片整改完成要传整改后照片安全隐患台账要挂附件——文件存储是EHS系统跑不掉的刚需。我一开始用本地磁盘存储文件存在项目根目录的upload文件夹下后来发现两个问题一是项目重新打包会覆盖文件二是论文里写文件存储在应用服务器本地磁盘显得不够现代化。于是换了MinIO一个开源的对象存储服务。SpringBoot整合MinIO的关键代码很简单Configuration public class MinioConfig { Bean public MinioClient minioClient() { return MinioClient.builder() .endpoint(http://localhost:9000) .credentials(minioadmin, minioadmin) .build(); } }上传文件时调readyBucket判断桶是否存在不存在则创建然后putObject上传返回文件访问路径。前端用el-image直接展示上传后的图片非常顺畅。MinIO有Web控制台演示之前先在浏览器里打开管理界面老师可以看到上传的隐患照片都在里面躺着很直观。5.4 图表和报表从数据到决策EHS系统没有报表和图表会显得很单薄。我做了三个维度的可视化安全驾驶舱首页展示未闭环隐患数、本月巡检完成率、隐患环比趋势折线图环境监测页近12个月废气排放趋势图柱状图加折线图组合健康管理页员工体检异常率统计、劳保用品到期数量提醒后端图表接口统一使用聚合查询public ListMapString, Object getTrendData(Integer months) { // 按月份分组统计隐患数量 return jdbcTemplate.queryForList( SELECT DATE_FORMAT(create_time, %Y-%m) as month, COUNT(*) as cnt FROM hazard WHERE create_time ? GROUP BY month, startTime); }前端用的是轻量级图表库考虑到毕设项目的定位不需要引入太重型的可视化组件能画折线图、柱状图、饼图就够了。报表导出用EasyExcel写一个监听器查询隐患台账列表调用ExcelWriter写入流前端一个按钮点击就下载。答辩前可以预生成一份真实感的月度隐患分析报告用导出的Excel跟在座老师展示比单纯看页面更能加分。6. 项目部署、演示数据和答辩准备的实战经验最后这部分说说这套系统的部署和答辩环节最容易忽略的事情。6.1 本地环境搭建和演示环境准备如果你的开发环境是Windows数据库和Redis服务装好之后重点检查几个配置文件application.ymlMySQL连接串的时区参数serverTimezone设为Asia/Shanghai否则日期字段会有8小时偏差Redis密码如果本地Redis没设密码配置里就留空但有密码时启动时会报认证失败MinIO端口默认9000注意防火墙放行启动顺序也很重要先启动MySQL和Redis再启动MinIO最后启动Spring Boot应用。我遇到过启动顺序写错导致应用连不上Redis的尴尬查了半天才发现是忘了启动服务。6.2 演示数据怎么造才真实毕设答辩最怕的场面是系统里空空荡荡老师一页页翻什么都没有。所以演示数据必须提前认真准备。我造数据的方式是写一个DataInitializer类项目启动时自动初始化创建5个用户管理员、安全主管、车间安全员、环境专员、普通员工密码统一123456录入20条隐患数据分布在不同月份状态覆盖各个阶段录入10个巡检点、30份巡检记录录入15名员工健康档案、若干条体检记录环境模块录入12个月的废气排放模拟数据日常待办、通知公告、操作日志也铺满这样打开系统后首页驾驶舱的数据图表不会是全空的各个模块点进去都有内容可看。这个环节很耗费耐心但直接决定答辩时的观感。6.3 答辩时容易被追问的三类技术问题结合我带毕设的经验EHS系统答辩时老师最容易追问这几个技术点安全隐患状态流转你是怎么保证数据一致性的回答思路状态变更限定在特定操作内每次流转增加状态校验同时通过日志表记录全部历史状态保证可回溯。JWT过期了用户怎么办回答思路JWT是无状态的过期后前端收到401状态码引导用户重新登录。业务上用了双token机制访问token短时效、刷新token长时效刷新token过期才强制重新登录。如果隐患数据量达到百万级别你的查询会慢吗回答思路隐患表在create_time和status上建了联合索引列表查询默认按创建时间倒序分页同时支持状态过滤。数据量大时可以引入读写分离或分表但这属于扩展方案。这三个问题的回答思路在开发时就要想清楚因为它们的答案其实都已经体现在你的代码设计里了。6.4 代码和论文对应表避免系统做完论文没得写最后给你一个非常实用的清单。很多同学系统做完了写论文时不知道哪些内容算工作量。建议你在开发时顺手做一张功能点-技术点-论文章节的对应记录页面仪表盘 - 聚合查询、定时任务 - 数据可视化章节隐患闭环 - 状态机设计、Quartz调度 - 系统详细设计章节角色权限 - Spring SecurityJWT - 系统安全设计章节MinIO文件上传 - 对象存储集成 - 系统集成章节Excel导出 - EasyExcel - 报表模块章节开发过程里随手记录写论文时会轻松一大截。7. 我做完这套系统后的几点心得EHS系统做完我自己最大的体会是这个题目选出来的效果上限取决于你对业务闭环的理解深度而不是技术栈的新旧。SpringBoot本身是个熟练工框架真正让系统亮眼的是隐患排查闭环设计、角色分权、状态机、定时任务整合这些能讲出逻辑的设计点。一个比较意外的收获是我在做定时任务超期提醒时为了验证逻辑反复调时间参数后来干脆把整改期限设计成了可配置项——管理员在系统设置里就能修改不同风险等级的整改时限。这个细节虽然不起眼但它在答辩时体现出了你对业务弹性的考虑比写一堆花哨代码有用得多。最后提醒一件事。如果你是纯新手开发顺序建议先做权限模块再做业务模块。因为所有页面都依赖登录用户信息地基不打牢后面每写一个模块都要翻回去修权限非常痛苦。我先做通了用户-角色-菜单这条链路后续隐患、巡检、健康档案都是在这个地基上快速垒起来的。这套系统如果你从零开始写预留三到四周比较稳妥第一周围绕环境搭建和数据建模第二周做权限和用户模块第三周做EHS三大业务闭环最后一周留给图表报表和演示数据准备。节奏稳住过程记录好不管是系统展示还是论文写作都会很从容。