简介本资源是一套面向高校计算机专业本科生的毕业设计级安全生产隐患排查与整治管理信息系统聚焦企业安全监管数字化场景解决隐患信息采集、整改跟踪、统计分析等核心业务闭环问题。系统采用前后端分离架构含SpringBoot 2后端端口8088、Vue2采集端与Vue3vue-admin管理端集成MyBatis-Plus、Redis及MySQL支持图片/视频附件上传与多维度数据看板。压缩包共310个文件涵盖102个Java后端逻辑类、59个JS交互脚本、46个Vue组件、18个XML配置与映射文件以及SQL数据库脚本、启动脚本bat、配置文件yml/yaml等结构完整、开箱即用总大小2.16MB。已有78人学习下载提供可直接运行的全栈源码、清晰分层的模块目录如UserController、Result统一响应、CorsConfig跨域配置、配套springboot-vue.sql数据库文件便于快速部署、二次开发与课程答辩演示。 又是一个毕业设计季后台留言里“安全生产隐患排查系统”这个题目的出现频率一直很高。说实话这类系统在功能上并不算复杂核心就是“排查-整改-复查-闭环”这条业务线但正因为它贴近企业真实管理场景非常适合用来展示SpringBoot Vue的全栈开发能力所以高校导师和企业评委都比较买账。我前前后后帮人看过不少类似的项目自己也完整落地过一版今天就把这套系统的设计思路、核心实现和踩坑记录都摊开来讲希望能给正在做这个题目的朋友一些实在的参考。先说清楚这套系统能做什么。简单来说它是一个围绕安全生产隐患排查治理全流程的管理平台覆盖了隐患排查登记、整改任务下发、整改结果反馈、复查验收、统计分析等环节。后端基于SpringBoot 2.x构建提供RESTful API接口前端采用Vue 2 Element UI搭建单页应用数据库使用MySQL 8.0通过MyBatis-Plus做ORM映射。整个项目结构清晰、代码量适中既符合毕业设计需要的“工作量”又不至于复杂到难以驾驭。这个题目适合谁来参考如果你正在准备毕业设计或者想快速上手一个真实可运行的全栈项目用于面试展示再或者你是刚入行的开发想了解企业管理系统的常见套路这篇文章都会对你有帮助。我会从整体设计、核心代码、实操流程、踩坑记录四个维度展开尽量把关键细节都讲到。1. 项目整体设计与思路拆解1.1 需求分析与功能模块划分拿到题目之后第一件事不是急着敲代码而是把需求理清楚。安全生产隐患排查与整治管理系统核心用户角色一般有三类排查人员负责现场检查并登记隐患、整改负责人接收整改任务并反馈结果、安全管理员复查验收、统计分析。有些场景下还会有普通员工角色用于查看与自己相关的隐患信息和整改情况但毕业设计阶段做到三类角色基本就够用了。功能模块上我把它拆成六大块系统管理用户管理、角色管理、菜单权限管理。这部分是框架的基础承担登录认证和权限控制。隐患排查管理排查任务的创建、分配、执行、记录包含排查计划、排查记录、隐患登记三个子模块。隐患整改管理整改通知下发、整改任务认领、整改进展上报、整改结果审核。复查验收管理对整改完成的隐患进行复查确认是否闭环支持复查不通过退回重新整改。统计报表按部门、隐患等级、整改状态、时间维度等做统计以图表形式展示。通知公告发布安全通知、整改催办消息简单实现站内信功能。这里要提醒一点模块划分不要贪多。很多同学喜欢把功能做得特别散菜单一大堆结果每个页面都只有一张空表。答辩时老师一问业务细节答不上来反而减分。把上面六个模块做扎实每个模块有独立业务逻辑足够撑起一个高质量的毕设。1.2 技术选型为什么是SpringBoot Vue这个题目直接指定了SpringBoot Vue那我们就顺着这个技术栈来选型。后端框架选SpringBoot 2.7.x而不是3.x。原因很现实3.x要求JDK 17部分老版本的依赖兼容性有问题而且网上大部分资料和教程都是基于2.x的遇到问题更容易搜到解决方案。毕业设计求稳能用成熟的版本就不要追新。持久层框架我选了MyBatis-Plus。它比原生MyBatis省事内置了通用Mapper和分页插件单表CRUD几乎不用写SQL能把开发效率提升一倍。多表关联和企业级复杂查询再手写XML灵活性也够。JPA虽然开发更快但稍微复杂一点儿的查询就让人头疼而且国内企业用MyBatis的更多写在简历上更有说服力。前端框架选择Vue 2 Element UI不是Vue 3 Element Plus。我不是说Vue 3不好但在毕业设计这个时间节点上Vue 2的生态更成熟Element UI组件完整遇到兼容性问题也更容易找到答案。如果你想用Vue 3记得把Element Plus和Vue Router 4、Pinia这些配套版本一并配上别版本混搭出怪问题。安全认证这块我用的是JWT Spring Security。JWT无状态适合前后端分离架构Spring Security负责过滤链和权限校验。Shiro也可以配置上更简单一些但Spring Security在企业项目中更主流作为毕设加分项更有说服力。前端脚手架直接上Vue CLI或Vite配合Axios做HTTP请求封装、ECharts做统计图表。权限控制用Vue Router的导航守卫配合后端返回的菜单权限动态生成路由。这套组合是当前中小型管理系统的主流方案实用性很强。1.3 数据库设计的核心考量数据库设计是整个系统的地基设计得好不好直接决定了后面编码是顺风顺水还是四处打补丁。我设计的主表有7张加上关系表一共10张左右下面是核心表结构sys_user用户表字段包括id、username、passwordBCrypt加密存储、real_name、phone、dept_id、status等。sys_role角色表字段包括id、role_name、role_code、remark。sys_user_role用户角色关系表多对多关联。sys_menu菜单权限表字段包括id、parent_id、menu_name、menu_type目录/菜单/按钮、path、component、perms等。biz_hidden_danger隐患表字段包括id、danger_code隐患编号、title、description、level一般/较大/重大、status排查中/待整改/整改中/待复查/已闭环、discover_user_id、discover_time、rectify_user_id、rectify_deadline等。biz_rectification整改记录表字段包括id、danger_id、rectify_user_id、rectify_content、rectify_time、attachment附件路径、rectify_result通过/不通过、review_user_id、review_time、review_comment。biz_inspection_plan排查计划表字段包括id、plan_name、plan_type、executor_id、plan_date、status、remark。在设计过程中有几个关键点值得注意第一隐患状态字段不要用字符串随意存要定义成整型枚举并在一张字典表里维护状态含义。我定义的状态流转是0-排查中、1-待整改、2-整改中、3-待复查、4-已闭环。这样在代码里做状态流转判断时清晰明了统计SQL写起来也方便。第二业务编号字段要单独设计。隐患编号是dang开头加年月日加四位序号比如dang202506210001。用时间戳做业务编号在查询时不友好这个字段是给人看的不是给机器看的。第三所有表都要加上create_time、update_time、create_by、update_by四个基础审计字段。这不光是规范排查问题时能直接定位是谁在什么时候改了什么数据实用性很强。MyBatis-Plus有MetaObjectHandler可以自动填充不用手写。2. 核心功能实现与关键代码解析2.1 隐患排查流程的状态机设计隐患排查整治的核心不是CRUD而是状态流转的控制。隐患从发现到闭环会经历一系列状态变化如果代码里放任任意状态随意跳转整个业务流程就会失控。我提供一段状态流转校验的方法统一放在Service层处理public void changeDangerStatus(Long dangerId, Integer targetStatus) { Danger danger dangerMapper.selectById(dangerId); if (danger null) { throw new ServiceException(隐患记录不存在); } Integer currentStatus danger.getStatus(); // 定义合法状态流转映射 // 0-排查中 - 1-待整改 // 1-待整改 - 2-整改中 // 2-整改中 - 3-待复查 // 3-待复查 - 4-已闭环 或 退回2-整改中 boolean isValid validTransition(currentStatus, targetStatus); if (!isValid) { throw new ServiceException(非法的状态流转: currentStatus - targetStatus); } danger.setStatus(targetStatus); dangerMapper.updateById(danger); } private boolean validTransition(Integer from, Integer to) { if (from null || to null) { return false; } if (from 0) return to 1; if (from 1) return to 2; if (from 2) return to 3; if (from 3) return to 2 || to 4; return false; }这段代码的思路是把状态流转规则收敛到一个方法里所有调用方都必须走这个方法而不是直接更新数据库的status字段。这样做的好处是无论前端从哪里发起请求后端都能保证业务规则不被绕过。实际操作中我还加了一个操作日志表记录每次状态变更的发起人、时间、原状态、目标状态、操作说明。答辩时老师如果问到“如何保证流程严谨性”这个日志表就是最好的回答。2.2 角色权限控制的落地方式权限控制是毕设答辩的高频考点也是很多同学的薄弱环节。我采用的是“RBAC 手动注解”模式比复杂的动态数据权限简单但比纯前端判断要严谨。后端权限控制的核心就在Spring Security的过滤链上。我重写了两个核心类UserDetailsServiceImpl负责根据用户名加载用户信息和角色权限JwtAuthenticationFilter负责拦截请求并解析Token把用户信息塞进SecurityContext。关键配置如下Configuration EnableWebSecurity EnableGlobalMethodSecurity(prePostEnabled true) public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http.csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeRequests() .antMatchers(/api/auth/login, /api/auth/register).permitAll() .antMatchers(/swagger-ui/**, /swagger-resources/**, /v2/api-docs).permitAll() .anyRequest().authenticated() .and() .addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class); } }然后在Controller的方法上使用PreAuthorize注解做细粒度控制// 只有安全管理员可以创建排查计划 PreAuthorize(hasRole(ADMIN)) PostMapping(/plan) public Result createPlan(RequestBody InspectionPlan plan) { return inspectionPlanService.savePlan(plan); } // 整改负责人角色可修改整改信息 PreAuthorize(hasAnyRole(ADMIN, RECTIFY)) PutMapping(/rectify) public Result updateRectify(RequestBody Rectification rectification) { return rectifyService.updateRectify(rectification); }权限模型设计上我把权限分成菜单权限和按钮权限。菜单权限控制用户能进入哪些页面按钮权限控制页面上哪些操作按钮可见可点。后端在查询用户信息时返回该用户的权限标识集合前端根据标识判断按钮是否展示。有一个实战细节要分享前端不能只做按钮隐藏还需要保留后端校验。因为攻击者完全可以绕过前端直接调后端接口前端隐藏只是体验优化后端拦截才是安全屏障。我在答辩演示时会特意演示一个场景用整改人员账号直接调用管理员的API后端返回403然后解释这就是“前后端双重校验”。2.3 隐患表单的动态化设计隐患排查过程中不同类型的隐患设备类、消防类、作业环境类对应的表单字段差异很大。如果为每种类型都建一张表数据库要炸如果只建一张大宽表空字段又太多。我采用了“主表 扩展字段JSON”的设计方案。隐患主表存通用字段扩展信息用extra_info字段存储JSON串。查询时把JSON解析出来动态展示在表单上提交时再序列化存进去。public class Danger { private Long id; private String dangerCode; private String title; private Integer level; private Integer status; private String description; private String extraInfo; // JSON字符串存储动态扩展字段 private Long discoverUserId; private LocalDateTime discoverTime; // getter/setter省略 }这样设计的好处显而易见新增隐患类型时不需要改表结构只要在前端表单配置项里增加字段即可。数据库字段不算多查询效率也有保障。使用JSON字段也要注意一个问题不要在SQL里对JSON字段做条件查询。比如“查询所有设备类型隐患中设备温度超过80度的记录”这种情况应该在业务层先把JSON解析出来再在内存中过滤或者把高频查询字段提升为独立字段。毕业设计的数据量一般不大内存过滤完全能接受但设计时要有这个意识答辩时能讲出权衡逻辑。2.4 上报统计报表的实现思路统计报表模块是让毕业设计从“管理系统”升级到“决策支持系统”的点睛之笔也是答辩时的展示亮点。我实现了三类统计第一类是隐患等级分布统计。按一般、较大、重大三个等级统计数量前端用饼图展示。SQL核心是SELECT level, COUNT(*) AS count FROM biz_hidden_danger WHERE create_time BETWEEN #{startTime} AND #{endTime} GROUP BY level;第二类是整改完成率趋势统计。按月份统计应整改数、已完成数、按期完成率。这里要注意“按期完成率”的口径定义整改完成时间小于等于整改期限的算按期完成超过期限的算逾期完成。第三类是部门隐患排名。关联部门表统计各部门隐患总数和未整改数用柱状图展示前10名。这个统计很有管理价值哪个部门安全状况差一目了然。后端接口的返回结构我统一设计成Map或自定义VO对象前端直接用ECharts渲染。值得注意的是经常有同学把统计逻辑写在前端从后端拉全量数据再在前端聚合。数据量小的时候没问题数据量一大页面直接卡死。聚合逻辑放在SQL里既能减轻传输压力又能利用数据库索引优化是更合理的设计。3. 实操过程从零搭建到跑通全流程3.1 环境准备与项目初始化在开始写代码之前要先把环境准备妥当。我的开发环境如下供参考组件版本备注JDK1.8SpringBoot 2.x兼容性最好Maven3.8.x依赖管理MySQL8.0数据库Node.js14.x/16.xVue 2项目构建IDEA2023.x集成开发环境Navicat16.x数据库可视化工具工程结构上我采用了前后端分离的两个目录backend放SpringBoot项目frontend放Vue项目。后端项目用IDEA的Spring Initializr创建前端用vue create frontend创建。后端项目的包结构如下com.example.safety ├── SafetyApplication.java // 启动类 ├── common/ // 通用模块 │ ├── result/ // 统一返回结果 │ ├── exception/ // 全局异常处理 │ └── utils/ // 工具类 ├── config/ // 配置类 │ ├── SecurityConfig.java // 安全配置 │ ├── MybatisPlusConfig.java // MyBatis-Plus配置 │ └── CorsConfig.java // 跨域配置 ├── controller/ // 控制器层 ├── service/ // 业务逻辑层 │ └── impl/ // 实现类 ├── mapper/ // 数据访问层 ├── entity/ // 实体类 └── dto/ // 数据传输对象分包清晰的目的有两个一是自己维护方便改一个功能不用全项目翻找二是答辩时老师看代码结构第一印象就好。3.2 数据库初始化与数据填充数据库脚本是整套系统能跑起来的关键也是很多人忽略的部分。我的数据库脚本文件包括三部分safety_schema.sql建库建表语句。safety_data.sql基础数据包括管理员账号、菜单数据、部门数据。safety_demo_data.sql演示数据包括几十条模拟隐患和整改记录覆盖不同状态和等级。提示一下演示数据一定要准备而且要有讲究。不能随便造几十条没有逻辑的数据要模拟真实业务场景。比如“5月份发现了一批消防设施隐患其中3条已完成整改闭环1条整改中超期2条等待复查”——这样的数据分布统计报表展示时才有故事可说。数据库初始化时有个细节要注意MySQL的字符集统一设置为utf8mb4排序规则utf8mb4_general_ci否则存中文和特殊符号时会出问题。3.3 后端核心接口开发流程后端开发我习惯按照“实体类 - Mapper - Service - Controller”的顺序来。第一步根据数据库表结构生成实体类。用MyBatis-Plus的代码生成器可以一键生成省时省力。但生成之后要检查字段类型是否和Java类型正确映射比如MySQL的datetime对应LocalDateTimetinyint对应Integer。第二步写业务逻辑。这是核心工作量所在以隐患登记为例业务流程是校验当前用户是否有隐患排查登记权限。校验必填字段是否完整隐患等级是否合法。生成隐患编号。保存隐患主记录状态设为“排查中”。如果是重大隐患自动发送站内通知给安全管理员并生成一条待办事项。第三步统一封装返回结果。我之前看过很多同学直接在Controller里返回各种Map或干脆返回一个字符串这样前后端联调时非常痛苦。我定义了一个统一返回体public class ResultT { private Integer code; // 200成功4xx业务错误500系统错误 private String message; // 提示信息 private T data; // 业务数据 public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }前端Axios拦截器统一判断code字段非200时弹消息提示。这样整个项目中返回格式统一前端处理逻辑也简单。3.4 前端页面的搭建与路由设计前端页面我按模块拆分了Vue组件核心页面包括登录页账号密码输入记住密码功能。首页/工作台展示当前用户的待办事项、本月隐患统计、快捷入口。隐患管理页隐患列表支持按状态、等级、时间筛选、新增/编辑隐患弹窗、隐患详情页。整改管理页待整改列表、整改进展上报表单支持附件上传。复查验收页待复查列表、复查结果表单通过/退回。统计报表页ECharts图表展示。系统管理页用户管理、角色管理、菜单管理。路由设计上采用动态路由方案。登录成功后后端返回当前用户的菜单权限前端根据权限动态生成路由。核心代码如下// 动态添加路由 function generateRoutes(menus) { const routes []; menus.forEach(menu { const route { path: menu.path, name: menu.name, component: loadView(menu.component), meta: { title: menu.title, icon: menu.icon } }; if (menu.children menu.children.length 0) { route.children generateRoutes(menu.children); } routes.push(route); }); return routes; } // 在路由守卫中动态注册 router.beforeEach((to, from, next) { const token getToken(); if (!token) { if (to.path /login) { next(); } else { next(/login); } return; } if (to.path /login) { next(/); return; } // 首次进入时动态添加路由 if (!store.state.permission.routesLoaded) { store.dispatch(permission/generateRoutes).then(accessRoutes { router.addRoutes(accessRoutes); next({ ...to, replace: true }); }); } else { next(); } });这个方案有一个需要在部署时注意的坑动态添加路由后刷新页面时路由表会重新初始化需要重新从后端拉取菜单。所以路由守卫里每次刷新都要判断routesLoaded状态否则会白屏。我在开发时遇到过一次排查了很久才发现是这个问题。Axios封装也很重要。我统一做了请求拦截器和响应拦截器请求拦截器自动附加Token响应拦截器统一处理错误码。另外还做了Token过期自动跳转登录页的处理// 响应拦截器 service.interceptors.response.use( response { const res response.data; if (res.code 401) { // Token过期或非法清除登录状态并跳转登录页 removeToken(); window.location.href /login; return Promise.reject(new Error(登录状态已过期)); } return res; }, error { if (error.response error.response.status 403) { ElementUI.Message.error(没有权限执行此操作); } return Promise.reject(error); } );3.5 前后端联调与部署验证前后端联调是毕业设计最容易翻车的环节。很多同学前端好了、后端好了一联调全是问题。我总结了几个联调前必须确认的点第一跨域问题。前端服务端口和后端服务端口不一致会产生跨域。后端已经配置了CorsConfig允许前端地址访问。如果配置了但还报跨域错误检查一下是否走了网关或Nginx代理代理层也要加跨域头。第二接口路径一致性。前端请求的URL路径必须和后端Controller的RequestMapping路径完全一致包括大小写。我习惯把后端接口统一以/api开头前端Axios的baseURL也设为http://localhost:8080/api减少路径拼接错误。第三日期格式。Java后端返回LocalDateTime默认序列化成数组格式前端显示会很难看。在application.yml中配置全局日期格式化spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8这样前后端传输的日期字符串格式统一为2025-06-21 14:30:00不会出现解析错误。4. 常见问题与排查技巧实录4.1 高频报错速查表这个部分我整理了一份高频问题排查表都是实际开发中反复出现的问题方便大家直接对照排查。错误类型典型报错信息原因分析解决方案启动失败Cannot determine embedded database driver class缺少数据库驱动依赖或数据源未配置检查pom.xml是否引入MySQL驱动application.yml中url、username、password是否正确启动失败Failed to configure a DataSource动态数据源或自动配置异常检查启动类上是否有excludeDataSourceAutoConfiguration.class的误用接口404No mapping found for HTTP request with URIController映射路径错误或类未扫描检查Controller类是否在启动类同包或子包下确认RequestMapping路径依赖冲突ClassNotFoundException: org.springframework.boot.context.properties.ConfigurationProperties版本兼容问题检查SpringBoot和SpringCloud版本是否匹配统一使用BOM管理前端白屏CORS policy: No Access-Control-Allow-Origin跨域配置缺失后端配置CorsConfig允许前端Origin上传失败MaxUploadSizeExceededException上传文件大小超限在application.yml中配置spring.servlet.multipart.max-file-size和max-request-sizeJWT过期JWT signature does not match密钥不一致或客户端篡改检查前后端密钥是否一致token解析时使用统一密钥中文乱码数据库中文显示??数据库连接参数未指定编码JDBC连接串拼上useUnicodetruecharacterEncodingutf-8这些报错大多都是配置层面的问题。经验是遇到报错先用浏览器开发工具的Network面板看请求是否到达了后端再去看后端的日志输出。通过判断“是前端没发请求、后端没收到请求、后端报错、前端渲染错误”的哪一段能快速缩小排查范围。4.2 毕业设计答辩技术问答锦囊答辩是毕业设计的最后一关技术问题答得好直接决定成绩档次。我整理了评委老师最常问的问题以及回答思路问题一你的系统权限控制是怎么实现的回答思路先说R本文还有配套的精品资源点击获取 SpringBoot+Vue全栈实战：安全生产隐患排查系统从0到1
简介本资源是一套面向高校计算机专业本科生的毕业设计级安全生产隐患排查与整治管理信息系统聚焦企业安全监管数字化场景解决隐患信息采集、整改跟踪、统计分析等核心业务闭环问题。系统采用前后端分离架构含SpringBoot 2后端端口8088、Vue2采集端与Vue3vue-admin管理端集成MyBatis-Plus、Redis及MySQL支持图片/视频附件上传与多维度数据看板。压缩包共310个文件涵盖102个Java后端逻辑类、59个JS交互脚本、46个Vue组件、18个XML配置与映射文件以及SQL数据库脚本、启动脚本bat、配置文件yml/yaml等结构完整、开箱即用总大小2.16MB。已有78人学习下载提供可直接运行的全栈源码、清晰分层的模块目录如UserController、Result统一响应、CorsConfig跨域配置、配套springboot-vue.sql数据库文件便于快速部署、二次开发与课程答辩演示。 又是一个毕业设计季后台留言里“安全生产隐患排查系统”这个题目的出现频率一直很高。说实话这类系统在功能上并不算复杂核心就是“排查-整改-复查-闭环”这条业务线但正因为它贴近企业真实管理场景非常适合用来展示SpringBoot Vue的全栈开发能力所以高校导师和企业评委都比较买账。我前前后后帮人看过不少类似的项目自己也完整落地过一版今天就把这套系统的设计思路、核心实现和踩坑记录都摊开来讲希望能给正在做这个题目的朋友一些实在的参考。先说清楚这套系统能做什么。简单来说它是一个围绕安全生产隐患排查治理全流程的管理平台覆盖了隐患排查登记、整改任务下发、整改结果反馈、复查验收、统计分析等环节。后端基于SpringBoot 2.x构建提供RESTful API接口前端采用Vue 2 Element UI搭建单页应用数据库使用MySQL 8.0通过MyBatis-Plus做ORM映射。整个项目结构清晰、代码量适中既符合毕业设计需要的“工作量”又不至于复杂到难以驾驭。这个题目适合谁来参考如果你正在准备毕业设计或者想快速上手一个真实可运行的全栈项目用于面试展示再或者你是刚入行的开发想了解企业管理系统的常见套路这篇文章都会对你有帮助。我会从整体设计、核心代码、实操流程、踩坑记录四个维度展开尽量把关键细节都讲到。1. 项目整体设计与思路拆解1.1 需求分析与功能模块划分拿到题目之后第一件事不是急着敲代码而是把需求理清楚。安全生产隐患排查与整治管理系统核心用户角色一般有三类排查人员负责现场检查并登记隐患、整改负责人接收整改任务并反馈结果、安全管理员复查验收、统计分析。有些场景下还会有普通员工角色用于查看与自己相关的隐患信息和整改情况但毕业设计阶段做到三类角色基本就够用了。功能模块上我把它拆成六大块系统管理用户管理、角色管理、菜单权限管理。这部分是框架的基础承担登录认证和权限控制。隐患排查管理排查任务的创建、分配、执行、记录包含排查计划、排查记录、隐患登记三个子模块。隐患整改管理整改通知下发、整改任务认领、整改进展上报、整改结果审核。复查验收管理对整改完成的隐患进行复查确认是否闭环支持复查不通过退回重新整改。统计报表按部门、隐患等级、整改状态、时间维度等做统计以图表形式展示。通知公告发布安全通知、整改催办消息简单实现站内信功能。这里要提醒一点模块划分不要贪多。很多同学喜欢把功能做得特别散菜单一大堆结果每个页面都只有一张空表。答辩时老师一问业务细节答不上来反而减分。把上面六个模块做扎实每个模块有独立业务逻辑足够撑起一个高质量的毕设。1.2 技术选型为什么是SpringBoot Vue这个题目直接指定了SpringBoot Vue那我们就顺着这个技术栈来选型。后端框架选SpringBoot 2.7.x而不是3.x。原因很现实3.x要求JDK 17部分老版本的依赖兼容性有问题而且网上大部分资料和教程都是基于2.x的遇到问题更容易搜到解决方案。毕业设计求稳能用成熟的版本就不要追新。持久层框架我选了MyBatis-Plus。它比原生MyBatis省事内置了通用Mapper和分页插件单表CRUD几乎不用写SQL能把开发效率提升一倍。多表关联和企业级复杂查询再手写XML灵活性也够。JPA虽然开发更快但稍微复杂一点儿的查询就让人头疼而且国内企业用MyBatis的更多写在简历上更有说服力。前端框架选择Vue 2 Element UI不是Vue 3 Element Plus。我不是说Vue 3不好但在毕业设计这个时间节点上Vue 2的生态更成熟Element UI组件完整遇到兼容性问题也更容易找到答案。如果你想用Vue 3记得把Element Plus和Vue Router 4、Pinia这些配套版本一并配上别版本混搭出怪问题。安全认证这块我用的是JWT Spring Security。JWT无状态适合前后端分离架构Spring Security负责过滤链和权限校验。Shiro也可以配置上更简单一些但Spring Security在企业项目中更主流作为毕设加分项更有说服力。前端脚手架直接上Vue CLI或Vite配合Axios做HTTP请求封装、ECharts做统计图表。权限控制用Vue Router的导航守卫配合后端返回的菜单权限动态生成路由。这套组合是当前中小型管理系统的主流方案实用性很强。1.3 数据库设计的核心考量数据库设计是整个系统的地基设计得好不好直接决定了后面编码是顺风顺水还是四处打补丁。我设计的主表有7张加上关系表一共10张左右下面是核心表结构sys_user用户表字段包括id、username、passwordBCrypt加密存储、real_name、phone、dept_id、status等。sys_role角色表字段包括id、role_name、role_code、remark。sys_user_role用户角色关系表多对多关联。sys_menu菜单权限表字段包括id、parent_id、menu_name、menu_type目录/菜单/按钮、path、component、perms等。biz_hidden_danger隐患表字段包括id、danger_code隐患编号、title、description、level一般/较大/重大、status排查中/待整改/整改中/待复查/已闭环、discover_user_id、discover_time、rectify_user_id、rectify_deadline等。biz_rectification整改记录表字段包括id、danger_id、rectify_user_id、rectify_content、rectify_time、attachment附件路径、rectify_result通过/不通过、review_user_id、review_time、review_comment。biz_inspection_plan排查计划表字段包括id、plan_name、plan_type、executor_id、plan_date、status、remark。在设计过程中有几个关键点值得注意第一隐患状态字段不要用字符串随意存要定义成整型枚举并在一张字典表里维护状态含义。我定义的状态流转是0-排查中、1-待整改、2-整改中、3-待复查、4-已闭环。这样在代码里做状态流转判断时清晰明了统计SQL写起来也方便。第二业务编号字段要单独设计。隐患编号是dang开头加年月日加四位序号比如dang202506210001。用时间戳做业务编号在查询时不友好这个字段是给人看的不是给机器看的。第三所有表都要加上create_time、update_time、create_by、update_by四个基础审计字段。这不光是规范排查问题时能直接定位是谁在什么时候改了什么数据实用性很强。MyBatis-Plus有MetaObjectHandler可以自动填充不用手写。2. 核心功能实现与关键代码解析2.1 隐患排查流程的状态机设计隐患排查整治的核心不是CRUD而是状态流转的控制。隐患从发现到闭环会经历一系列状态变化如果代码里放任任意状态随意跳转整个业务流程就会失控。我提供一段状态流转校验的方法统一放在Service层处理public void changeDangerStatus(Long dangerId, Integer targetStatus) { Danger danger dangerMapper.selectById(dangerId); if (danger null) { throw new ServiceException(隐患记录不存在); } Integer currentStatus danger.getStatus(); // 定义合法状态流转映射 // 0-排查中 - 1-待整改 // 1-待整改 - 2-整改中 // 2-整改中 - 3-待复查 // 3-待复查 - 4-已闭环 或 退回2-整改中 boolean isValid validTransition(currentStatus, targetStatus); if (!isValid) { throw new ServiceException(非法的状态流转: currentStatus - targetStatus); } danger.setStatus(targetStatus); dangerMapper.updateById(danger); } private boolean validTransition(Integer from, Integer to) { if (from null || to null) { return false; } if (from 0) return to 1; if (from 1) return to 2; if (from 2) return to 3; if (from 3) return to 2 || to 4; return false; }这段代码的思路是把状态流转规则收敛到一个方法里所有调用方都必须走这个方法而不是直接更新数据库的status字段。这样做的好处是无论前端从哪里发起请求后端都能保证业务规则不被绕过。实际操作中我还加了一个操作日志表记录每次状态变更的发起人、时间、原状态、目标状态、操作说明。答辩时老师如果问到“如何保证流程严谨性”这个日志表就是最好的回答。2.2 角色权限控制的落地方式权限控制是毕设答辩的高频考点也是很多同学的薄弱环节。我采用的是“RBAC 手动注解”模式比复杂的动态数据权限简单但比纯前端判断要严谨。后端权限控制的核心就在Spring Security的过滤链上。我重写了两个核心类UserDetailsServiceImpl负责根据用户名加载用户信息和角色权限JwtAuthenticationFilter负责拦截请求并解析Token把用户信息塞进SecurityContext。关键配置如下Configuration EnableWebSecurity EnableGlobalMethodSecurity(prePostEnabled true) public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http.csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeRequests() .antMatchers(/api/auth/login, /api/auth/register).permitAll() .antMatchers(/swagger-ui/**, /swagger-resources/**, /v2/api-docs).permitAll() .anyRequest().authenticated() .and() .addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class); } }然后在Controller的方法上使用PreAuthorize注解做细粒度控制// 只有安全管理员可以创建排查计划 PreAuthorize(hasRole(ADMIN)) PostMapping(/plan) public Result createPlan(RequestBody InspectionPlan plan) { return inspectionPlanService.savePlan(plan); } // 整改负责人角色可修改整改信息 PreAuthorize(hasAnyRole(ADMIN, RECTIFY)) PutMapping(/rectify) public Result updateRectify(RequestBody Rectification rectification) { return rectifyService.updateRectify(rectification); }权限模型设计上我把权限分成菜单权限和按钮权限。菜单权限控制用户能进入哪些页面按钮权限控制页面上哪些操作按钮可见可点。后端在查询用户信息时返回该用户的权限标识集合前端根据标识判断按钮是否展示。有一个实战细节要分享前端不能只做按钮隐藏还需要保留后端校验。因为攻击者完全可以绕过前端直接调后端接口前端隐藏只是体验优化后端拦截才是安全屏障。我在答辩演示时会特意演示一个场景用整改人员账号直接调用管理员的API后端返回403然后解释这就是“前后端双重校验”。2.3 隐患表单的动态化设计隐患排查过程中不同类型的隐患设备类、消防类、作业环境类对应的表单字段差异很大。如果为每种类型都建一张表数据库要炸如果只建一张大宽表空字段又太多。我采用了“主表 扩展字段JSON”的设计方案。隐患主表存通用字段扩展信息用extra_info字段存储JSON串。查询时把JSON解析出来动态展示在表单上提交时再序列化存进去。public class Danger { private Long id; private String dangerCode; private String title; private Integer level; private Integer status; private String description; private String extraInfo; // JSON字符串存储动态扩展字段 private Long discoverUserId; private LocalDateTime discoverTime; // getter/setter省略 }这样设计的好处显而易见新增隐患类型时不需要改表结构只要在前端表单配置项里增加字段即可。数据库字段不算多查询效率也有保障。使用JSON字段也要注意一个问题不要在SQL里对JSON字段做条件查询。比如“查询所有设备类型隐患中设备温度超过80度的记录”这种情况应该在业务层先把JSON解析出来再在内存中过滤或者把高频查询字段提升为独立字段。毕业设计的数据量一般不大内存过滤完全能接受但设计时要有这个意识答辩时能讲出权衡逻辑。2.4 上报统计报表的实现思路统计报表模块是让毕业设计从“管理系统”升级到“决策支持系统”的点睛之笔也是答辩时的展示亮点。我实现了三类统计第一类是隐患等级分布统计。按一般、较大、重大三个等级统计数量前端用饼图展示。SQL核心是SELECT level, COUNT(*) AS count FROM biz_hidden_danger WHERE create_time BETWEEN #{startTime} AND #{endTime} GROUP BY level;第二类是整改完成率趋势统计。按月份统计应整改数、已完成数、按期完成率。这里要注意“按期完成率”的口径定义整改完成时间小于等于整改期限的算按期完成超过期限的算逾期完成。第三类是部门隐患排名。关联部门表统计各部门隐患总数和未整改数用柱状图展示前10名。这个统计很有管理价值哪个部门安全状况差一目了然。后端接口的返回结构我统一设计成Map或自定义VO对象前端直接用ECharts渲染。值得注意的是经常有同学把统计逻辑写在前端从后端拉全量数据再在前端聚合。数据量小的时候没问题数据量一大页面直接卡死。聚合逻辑放在SQL里既能减轻传输压力又能利用数据库索引优化是更合理的设计。3. 实操过程从零搭建到跑通全流程3.1 环境准备与项目初始化在开始写代码之前要先把环境准备妥当。我的开发环境如下供参考组件版本备注JDK1.8SpringBoot 2.x兼容性最好Maven3.8.x依赖管理MySQL8.0数据库Node.js14.x/16.xVue 2项目构建IDEA2023.x集成开发环境Navicat16.x数据库可视化工具工程结构上我采用了前后端分离的两个目录backend放SpringBoot项目frontend放Vue项目。后端项目用IDEA的Spring Initializr创建前端用vue create frontend创建。后端项目的包结构如下com.example.safety ├── SafetyApplication.java // 启动类 ├── common/ // 通用模块 │ ├── result/ // 统一返回结果 │ ├── exception/ // 全局异常处理 │ └── utils/ // 工具类 ├── config/ // 配置类 │ ├── SecurityConfig.java // 安全配置 │ ├── MybatisPlusConfig.java // MyBatis-Plus配置 │ └── CorsConfig.java // 跨域配置 ├── controller/ // 控制器层 ├── service/ // 业务逻辑层 │ └── impl/ // 实现类 ├── mapper/ // 数据访问层 ├── entity/ // 实体类 └── dto/ // 数据传输对象分包清晰的目的有两个一是自己维护方便改一个功能不用全项目翻找二是答辩时老师看代码结构第一印象就好。3.2 数据库初始化与数据填充数据库脚本是整套系统能跑起来的关键也是很多人忽略的部分。我的数据库脚本文件包括三部分safety_schema.sql建库建表语句。safety_data.sql基础数据包括管理员账号、菜单数据、部门数据。safety_demo_data.sql演示数据包括几十条模拟隐患和整改记录覆盖不同状态和等级。提示一下演示数据一定要准备而且要有讲究。不能随便造几十条没有逻辑的数据要模拟真实业务场景。比如“5月份发现了一批消防设施隐患其中3条已完成整改闭环1条整改中超期2条等待复查”——这样的数据分布统计报表展示时才有故事可说。数据库初始化时有个细节要注意MySQL的字符集统一设置为utf8mb4排序规则utf8mb4_general_ci否则存中文和特殊符号时会出问题。3.3 后端核心接口开发流程后端开发我习惯按照“实体类 - Mapper - Service - Controller”的顺序来。第一步根据数据库表结构生成实体类。用MyBatis-Plus的代码生成器可以一键生成省时省力。但生成之后要检查字段类型是否和Java类型正确映射比如MySQL的datetime对应LocalDateTimetinyint对应Integer。第二步写业务逻辑。这是核心工作量所在以隐患登记为例业务流程是校验当前用户是否有隐患排查登记权限。校验必填字段是否完整隐患等级是否合法。生成隐患编号。保存隐患主记录状态设为“排查中”。如果是重大隐患自动发送站内通知给安全管理员并生成一条待办事项。第三步统一封装返回结果。我之前看过很多同学直接在Controller里返回各种Map或干脆返回一个字符串这样前后端联调时非常痛苦。我定义了一个统一返回体public class ResultT { private Integer code; // 200成功4xx业务错误500系统错误 private String message; // 提示信息 private T data; // 业务数据 public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }前端Axios拦截器统一判断code字段非200时弹消息提示。这样整个项目中返回格式统一前端处理逻辑也简单。3.4 前端页面的搭建与路由设计前端页面我按模块拆分了Vue组件核心页面包括登录页账号密码输入记住密码功能。首页/工作台展示当前用户的待办事项、本月隐患统计、快捷入口。隐患管理页隐患列表支持按状态、等级、时间筛选、新增/编辑隐患弹窗、隐患详情页。整改管理页待整改列表、整改进展上报表单支持附件上传。复查验收页待复查列表、复查结果表单通过/退回。统计报表页ECharts图表展示。系统管理页用户管理、角色管理、菜单管理。路由设计上采用动态路由方案。登录成功后后端返回当前用户的菜单权限前端根据权限动态生成路由。核心代码如下// 动态添加路由 function generateRoutes(menus) { const routes []; menus.forEach(menu { const route { path: menu.path, name: menu.name, component: loadView(menu.component), meta: { title: menu.title, icon: menu.icon } }; if (menu.children menu.children.length 0) { route.children generateRoutes(menu.children); } routes.push(route); }); return routes; } // 在路由守卫中动态注册 router.beforeEach((to, from, next) { const token getToken(); if (!token) { if (to.path /login) { next(); } else { next(/login); } return; } if (to.path /login) { next(/); return; } // 首次进入时动态添加路由 if (!store.state.permission.routesLoaded) { store.dispatch(permission/generateRoutes).then(accessRoutes { router.addRoutes(accessRoutes); next({ ...to, replace: true }); }); } else { next(); } });这个方案有一个需要在部署时注意的坑动态添加路由后刷新页面时路由表会重新初始化需要重新从后端拉取菜单。所以路由守卫里每次刷新都要判断routesLoaded状态否则会白屏。我在开发时遇到过一次排查了很久才发现是这个问题。Axios封装也很重要。我统一做了请求拦截器和响应拦截器请求拦截器自动附加Token响应拦截器统一处理错误码。另外还做了Token过期自动跳转登录页的处理// 响应拦截器 service.interceptors.response.use( response { const res response.data; if (res.code 401) { // Token过期或非法清除登录状态并跳转登录页 removeToken(); window.location.href /login; return Promise.reject(new Error(登录状态已过期)); } return res; }, error { if (error.response error.response.status 403) { ElementUI.Message.error(没有权限执行此操作); } return Promise.reject(error); } );3.5 前后端联调与部署验证前后端联调是毕业设计最容易翻车的环节。很多同学前端好了、后端好了一联调全是问题。我总结了几个联调前必须确认的点第一跨域问题。前端服务端口和后端服务端口不一致会产生跨域。后端已经配置了CorsConfig允许前端地址访问。如果配置了但还报跨域错误检查一下是否走了网关或Nginx代理代理层也要加跨域头。第二接口路径一致性。前端请求的URL路径必须和后端Controller的RequestMapping路径完全一致包括大小写。我习惯把后端接口统一以/api开头前端Axios的baseURL也设为http://localhost:8080/api减少路径拼接错误。第三日期格式。Java后端返回LocalDateTime默认序列化成数组格式前端显示会很难看。在application.yml中配置全局日期格式化spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8这样前后端传输的日期字符串格式统一为2025-06-21 14:30:00不会出现解析错误。4. 常见问题与排查技巧实录4.1 高频报错速查表这个部分我整理了一份高频问题排查表都是实际开发中反复出现的问题方便大家直接对照排查。错误类型典型报错信息原因分析解决方案启动失败Cannot determine embedded database driver class缺少数据库驱动依赖或数据源未配置检查pom.xml是否引入MySQL驱动application.yml中url、username、password是否正确启动失败Failed to configure a DataSource动态数据源或自动配置异常检查启动类上是否有excludeDataSourceAutoConfiguration.class的误用接口404No mapping found for HTTP request with URIController映射路径错误或类未扫描检查Controller类是否在启动类同包或子包下确认RequestMapping路径依赖冲突ClassNotFoundException: org.springframework.boot.context.properties.ConfigurationProperties版本兼容问题检查SpringBoot和SpringCloud版本是否匹配统一使用BOM管理前端白屏CORS policy: No Access-Control-Allow-Origin跨域配置缺失后端配置CorsConfig允许前端Origin上传失败MaxUploadSizeExceededException上传文件大小超限在application.yml中配置spring.servlet.multipart.max-file-size和max-request-sizeJWT过期JWT signature does not match密钥不一致或客户端篡改检查前后端密钥是否一致token解析时使用统一密钥中文乱码数据库中文显示??数据库连接参数未指定编码JDBC连接串拼上useUnicodetruecharacterEncodingutf-8这些报错大多都是配置层面的问题。经验是遇到报错先用浏览器开发工具的Network面板看请求是否到达了后端再去看后端的日志输出。通过判断“是前端没发请求、后端没收到请求、后端报错、前端渲染错误”的哪一段能快速缩小排查范围。4.2 毕业设计答辩技术问答锦囊答辩是毕业设计的最后一关技术问题答得好直接决定成绩档次。我整理了评委老师最常问的问题以及回答思路问题一你的系统权限控制是怎么实现的回答思路先说R本文还有配套的精品资源点击获取