坦白说，接这套"基于Java Web的安全生产线巡检管理系统"之前，我一直以为巡检软件的难点主要在技术实现层面。结果从项目一开始对接，现场管理人员反复问我的不是接口怎么写、报表怎么做，而是更扎心的问题：你怎么保证巡检员真的走到了设备旁边？你怎么证明纸上的记录不是下班前补填的？异常报上来了，谁跟进、怎么闭环？
这套系统的价值，恰恰就藏在这些问题里。它不是一个简单的CRUD管理后台，而是把"巡检任务下达、现场执行记录、异常上报处置、复查归档、统计考核"串成一条完整数据链路的业务系统。的确，网上类似的开源项目很多，但大多数只做了"巡检记录登记"这一层，真正面向生产现场、基层班组、安全管理三条线协同的系统成型方案反而少见。本文会从需求梳理、技术选型、数据库建模、核心功能实现、统计口径到踩坑经验逐一展开，适合正在做企业信息化系统的工程师，也适合刚学完Spring Boot想找一个完整项目练手的同学。
1. 现场巡检的信任危机：这个系统要解决什么问题
1.1 纸质巡检的四个系统性漏洞
项目启动前，我专门跑到车间跟了三天班组。不夸张地说，当时的巡检现状可以用四个词概括：漏检、补填、后补、难查。
先说漏检。巡检计划排得再密，人的精力是有限的，一个班次要跑几十个点位，到下午两三点人一疲惫，就很容易跳着走。纸质表上照样打勾，谁也不知道到底去没去。
再说补填，这是最普遍的问题。纸上记录有个天然的漏洞——它没办法证明填写时间。很多人习惯把一整天要填的表先带上，趁空闲一次性全打钩，等真正巡检的时候反而走马观花。这种"先填后巡"和"先巡后填"的次序问题，纸面上根本体现不出来。
第三个是异常上报严重滞后。巡检员在6号配电柜发现指示灯异常，写在纸上之后，要等整个班次结束后交到班组长手里，班组长再登记到台帐，维修人员看到工单最快也是第二天的事。一个隐患在车间里晾了一整夜，这在我们这个行业里是不允许的。
最后一个则是考核无据可依。月度安全考核时，领导问"这个月漏检率多少"，管理员的回答往往是"大概百分之十几吧"或者"我让下面统计一下"。口径还不统一，一个班组按点位算，另一个班组按任务算，数据根本没法横向比较。
1.2 系统的用户角色与核心业务边界
经过十几轮需求访谈，我把使用这套系统的人分成了四类：
- 巡检员：每天在手机上接收任务，到达现场扫码打卡，逐项记录检查结果；
- 班组长：负责核验异常情况，对误报进行关闭，对真实异常发起处理流程；
- 维修人员：接收异常工单，处理完成后提交处理结果；
- 安全生产管理员：制定巡检计划、查看全局执行数据、督办未闭环异常。
基于这些角色，系统的核心功能边界收敛为六个模块：基础数据（产线、巡检点、设备）、巡检计划、任务执行、异常闭环、统计报表、系统权限。这个边界确定之后，后面所有设计都没有跑偏。
与其把功能铺得很宽，不如先把一条主线打透。这是我在需求阶段的第一个重要判断。
1.3 功能优先级排序：先保闭环，再谈优化
需求方最初提了很多"锦上添花"的功能，比如扫码自动识别设备型号、语音录入巡检结果、自动生成隐患整改通知书。我的处理方式是把它们全部排到二期，原因很简单：一期必须解决"记录可信、异常可溯、数据可算"这三个基本问题，否则任何上层功能都是空中楼阁。
这个取舍很重要。在验收时，真正打动管理层的恰恰是这套闭环——扫码签到校验点位、异常推送直达维修、复查确认自动归档。
2. 技术选型不跟风：这套组合为什么能落地
2.1 后端框架：从SSH到Spring Boot，核心是降低维护成本
后端框架我选了Spring Boot 2.7.x。这里要说清楚，不是Spring Boot比Spring MVC高级多少，而是它把配置工作量压到了最低。巡检系统这种典型的业务管理系统，70%以上的代码是增删改查和状态流转，把精力花在XML配置上毫无意义。
持久层用了MyBatis-Plus。为什么不用JPA？JPA在简单场景下确实方便，但在复杂统计SQL、动态多条件查询上，MyBatis的灵活性和可控性优势明显。尤其是巡检系统里大量"按产线+时间+状态组合查询"的场景，MyBatis-Plus的LambdaQueryWrapper写起来几乎接近自然语言：
// 查询某产线下最近一小时处于执行中的巡检任务 List<InspectionTask> taskList = inspectionTaskMapper.selectList( Wrappers.<InspectionTask>lambdaQuery() .eq(InspectionTask::getLineId, lineId) .eq(InspectionTask::getStatus, "EXECUTING") .ge(InspectionTask::getPlanStartTime, LocalDateTime.now().minusHours(1)) );一行LambdaQuery，编译期就会校验字段名，改表名字段的时候基本不会出现"字符串SQL写错还不知道"的低级问题。
数据库用的是MySQL 8.0。这个选型没什么悬念——企业内网环境对国产化数据库有要求的话，MySQL的数据结构迁移到其他兼容数据库也相对顺滑。数据量层面，一般制造企业一天几千到两万条巡检记录，MySQL配合合理的索引结构毫无压力。
2.2 前端和移动端：PC端做管理，手机端做执行
前端选了Vue 2 + Element UI。现在Vue 3已经很成熟了，为什么还用Vue 2？说白了是团队熟悉度和组件生态的问题。项目要快速交付，团队成员脑子里已经积累了Vue 2的组件模式，强行上Vue 3还得重新踩一轮坑。如果一个新团队从零启动，我也建议直接用Vue 3，但接手一个要稳定交付的系统，稳比新重要。
移动端是整个系统的重头。现场巡检人员每天接触最多的不是电脑，而是手机。所以移动端我没有单独开发原生App，而是采用移动Web落地，理由很现实：
- 原生App需要上架、安装、升级，现场几百个人，光推动装App就是巨大的运维负担；
- 移动Web扫码即用，不管是微信内置浏览器、钉钉还是手机自带浏览器，打开链接就能干活。
信号问题是车间场景的常态。我在移动端做了Service Worker缓存，巡检入口页和任务列表页在首次加载后缓存到本地，二次打开速度会快很多。但要坦白说，这只是弱网优化，不是离线提交。真正要支持完全离线，需要浏览器的IndexedDB做本地队列，逻辑复杂度和工作量会成倍增加，建议放到二期根据实际需求评估。
2.3 整体部署架构
部署结构并不复杂：前端Nginx托管静态文件并反代API请求，后端Jar包部署在应用服务器上，MySQL做数据持久化，Redis做会话管理和热点数据缓存。
这套架构单体味很浓，但从成本、维护、稳定性角度讲，对一个内部管理系统是合适的。系统上线初期用户量只有几百人，并发量极低，单体架构反而减少了服务间通信的故障点。真要到了多产线、多基地部署的阶段，再拆分成微服务也不迟。
3. 数据库设计：巡检数据如何承载统计与分析
3.1 八张核心业务表
数据库是整个系统最不能返工的部分。我在设计时反复推演了三版才定稿，最终核心表结构如下：
| 表名 | 作用 | 关键字段 |
|---|---|---|
| line | 产线/区域 | id, line_name, leader_id |
| inspection_point | 巡检点 | id, line_id, point_name, qr_code |
| inspection_item | 检查项 | id, point_id, item_name, check_type, threshold |
| inspection_plan | 巡检计划 | id, plan_name, line_id, cycle_type, start_time, end_time |
| inspection_task | 巡检任务实例 | id, plan_id, task_date, executor_id, status |
| inspection_record | 巡检记录 | id, task_id, point_id, item_id, result_value, status |
| exception_case | 异常记录 | id, record_id, level, description, photo_url, status |
| exception_log | 异常流转日志 | id, exception_id, action, operator_id, remark |
其中，inspection_record是数据量最大的表，每月可能累计几十万行。在设计它的时候，我特意冗余了point_name、line_name、task_no几个字段。这违反了第三范式，但换来了查询效率。统计报表页最常干的事是按产线和日期查记录，如果每次都要join三张表才能展示基本信息，SQL复杂度和数据库压力都会上升。对这种高频查询场景，适度冗余换取性能是值得的。
3.2 计划与任务必须分离
这是我在设计中对后期影响最大的一步：巡检计划是模板，巡检任务是实例。
inspection_plan记录的是"什么产线、多久巡一次、检查哪些点位"这种静态配置；inspection_task记录的是"某一次实际执行"——执行人是谁、计划起止时间、实际完成时间、状态如何。
有人会问，这样做不是多了一张表吗？直接复用计划表不行吗？答案是绝对不行。如果没有计划和任务的分离，你做漏检率统计时就会遇到这种情况：某计划本周被临时取消了，但统计系统还认为它应该执行；某计划延期到明天，今天的统计口径又要怎么处理？将模板和实例分离之后，"应执行任务数"在任务生成那一刻就冻结了，统计口径始终一致，后期永远不会扯皮。
3.3 巡检记录的状态机设计
巡检记录表除了存储结果，核心还有一个字段是status，取值有：PENDING（待执行）、DONE（已完成）、ABNORMAL（有异常）、MISSED（漏检）。每一条待执行记录在任务生成时先入表，巡检员提交后再更新状态。这样统计模块的分母从一开始就锁死，不会被中途追加巡检点这种操作污染数据。
这里给一个关键提示：不要在业务表里保存字符串状态还放任程序员随便update。尽量把状态流转收敛到Service层，甚至抽象成简单状态机。巡检记录有四种状态，异常记录有五种状态，它们之间的合法流转必须由代码逻辑控制，而不是自由修改，否则最终统计出来的数据会千奇百怪。
4. 巡检闭环怎么跑通：任务生成、扫码执行、异常处置
4.1 任务生成器的三个细节
巡检任务生成我用了一个Spring定时任务，每天凌晨扫描所有启用状态的计划，满足条件就生成当天的任务。
@Scheduled(cron = "0 1 0 * * ?") public void generateDailyTasks() { List<InspectionPlan> plans = planMapper.selectList( Wrappers.<InspectionPlan>lambdaQuery() .eq(InspectionPlan::getStatus, "ENABLED")); for (InspectionPlan plan : plans) { if (needGenerateToday(plan)) { generateTaskForPlan(plan, LocalDate.now()); } } }这里有三个容易被忽略的点：
- 生成时间必须早于最早班次。如果最早班次6点开始，任务生成就要在6点前完成。我设成凌晨0点1分，既避开零点整的数据库任务高峰，又留足了缓冲。
- 幂等设计。系统如果以多实例部署或者定时任务被意外触发两次，就可能生成重复任务。解决办法是在
inspection_task表上加唯一索引（plan_id + task_date），插入冲突时捕获异常跳过，从源头堵死重复数据。 - 扫描范围要限定。有些计划只在工作日执行，有些只在周末执行，周期判断逻辑我封装成一个独立方法
needGenerateToday，不要在定时器里乱写if分支。
4.2 扫码签到：用操作成本换记录真实性
每个巡检点都会打印一张专属二维码，贴在设备或柜体上。巡检员到达现场后，用手机扫描二维码，系统校验该巡号是否属于当前任务有效范围，校验通过才能弹出检查项列表。
这一步表面上是多了一次扫码动作，实际操作成本也就两三秒，但它带来的好处远超成本：巡检员必须站在设备旁边才能完成记录，从机制上杜绝了"人在远处把点都打了"的情况。更进一步，系统可以记录每个点位的扫码时间和提交时间，两者相减就是这个点位的实际停留时长。正常检查一个空压机点位至少需要十几秒，如果有人两秒就提交，这条记录会被自动标记为"疑似快速填报"，供管理人员抽检。
提示：二维码内容不要直接用数据库主键ID，建议用一串随机UUID，并把点位编号拼接进去。一是防止别人遍历ID猜出巡检点规模，二是二维码可以定期重新打印而不影响业务逻辑。
4.3 异常状态机：从发现到闭环的全过程留痕
异常处置是巡检系统业务链路上最容易烂尾的环节。很多系统做了异常上报，却没有跟进这个异常后续到底处理了没有。我的方案是给异常案件设计一个五状态流转：待复核->处理中->待复查->已闭环，另外还有误报关闭。
巡检员上报异常后，状态是"待复核"。班组长到现场核实，如果是误报，直接关闭并写备注；如果属实，则指派给维修人员，状态变为"处理中"。维修完成提交结果后，状态变"待复查"，由原巡检员或班组长复查确认，确认通过归档为"已闭环"。
每一次状态变化，都必须写一条exception_log记录，记录操作人、动作、时间、备注。为什么这么严格？安全生产管理最讲究"责任可追溯"，一旦出了问题，系统要能完整回答"谁在什么时间发现、谁处理的、谁复查的"，这就是系统的信任基础。
5. 决策层看什么：核心指标的统计口径与实现
5.1 三个核心指标的定义
系统上线后的验收阶段，管理层问得最多的就是三个指标：
- 计划完成率：当期实际完成任务数 / 当期应执行任务数；
- 点位漏检率：未执行巡检记录数 / 应执行巡检记录数；
- 异常闭环率：已闭环异常数 / （上报异常总数 - 误报关闭数）。
这三个指标看着很直白，实际落地时细节问题特别多。比如"应执行巡检记录数"，我用的是任务生成时立即批量生成的inspection_record初始数量。好处是分母恒定，不会因为巡检员临时增加点位而变化。
5.2 SQL实现与延时剔除
计划完成率的统计SQL核心就是加GROUP BY和聚合条件：
SELECT l.line_name, COUNT(t.id) AS total_tasks, SUM(CASE WHEN t.status = 'FINISHED' THEN 1 ELSE 0 END) AS finished_tasks, ROUND(SUM(CASE WHEN t.status = 'FINISHED' THEN 1 ELSE 0 END) / COUNT(t.id) * 100, 2) AS finish_rate FROM inspection_task t JOIN line l ON t.line_id = l.id WHERE t.task_date BETWEEN '2024-06-01' AND '2024-06-30' GROUP BY t.line_id, l.line_name ORDER BY finish_rate ASC;及时率则要更小心。一个任务计划在8:00到10:00完成，巡检员10:05才提交，任务算完成了，但不能算"及时完成"。判断条件是任务的实际完成时间与计划截止时间做比较。
这里做特殊处理是"异常延时剔除"。如果某个任务关联的异常仍处于"处理中"状态，说明巡检员可能因为等维修人员而耽误了时间，这种情况下统计及时率时把延时时间段扣除，否则对一线人员不公平。
5.3 报表展示与导出
展示端用的ECharts，折线图展示趋势、柱状图做横向比较，按产线、班组、日期三个维度切换。ECharts难点不在于配置项，而在于把后端返回的统计JSON结构对齐到图表组件。我建议后端接口直接返回前端友好的结构，比如ECharts要求的{ name: ['1月','2月'], value: [90, 92] }这种格式，而不是把最原始的Map抛给前端自己拼。
导出用POI组件生成Excel，带格式的合并单元格要仔细设计。如果只是纯数据导出，CSV加UTF-8 BOM的做法更轻量，也不会乱码。但客户明确要整理好的报表，所以我选了POI。导出文件较大时，记得设置合理的响应头和内容长度，避免前端拿到损坏文件还查不出原因。
6. 权限、安全与性能：上线前必须处理的细节
6.1 RBAC权限与行级数据隔离
权限模型直接用RBAC，角色划分为系统管理员、安全生产管理员、班组长、巡检员、维修人员五类。权限控制不只是控制菜单显示，还要做数据权限。比如班组长登录后只能看到本班组的数据，巡检员只能看到自己的任务，管理员能看到全部。
数据权限的实现方式是在查询条件中根据当前登录用户的角色动态拼接过滤条件。我用AOP切面统一处理，定义一个@DataScope注解，Service层方法标记后自动注入过滤条件，避免每个方法都手写一遍数据权限判断。
| 角色 | 菜单范围 | 数据范围 |
|---|---|---|
| 系统管理员 | 用户、基础数据、参数配置 | 全局 |
| 安全生产管理员 | 计划、任务、统计、督办 | 全局 |
| 班组长 | 本班组任务、异常复核、复查 | 本班组 |
| 巡检员 | 我的任务、我的记录 | 本人 |
| 维修人员 | 异常工单、处理提交 | 本人所属区域 |
6.2 JWT与接口安全
前后端分离架构下，身份认证用JWT Token。登录成功后签发Token，前端每次请求带上，后端用拦截器校验。这里要提醒，JWT存到本地时要防止XSS窃取，前端存储尽量用HttpOnly Cookie而不是localStorage，能大幅降低被脚本读取的风险。
接口层面的防护还做了几件事：敏感接口二次校验角色、参数强制校验、文件上传白名单检查、统一异常处理避免SQL报错信息直接返回给前端。安全生产系统涉及的数据一旦出问题就不是小事，安全不能省。
6.3 性能优化三板斧
- 巡检记录表按月分区。单表数据量上百万后查询性能会明显下降，按月分区配合查询条件里强制走分区键，效果立竿见影。
- 统计结果预聚合。报表页面最怕每次访问都去全量聚合几十万行数据。我用定时任务在凌晨把前一天的统计结果汇总到统计表中，页面只查汇总表即可。
- 基础数据缓存。巡检点和产线信息不常变化，查询时优先走Redis缓存，缓存空着再查数据库并回填，可以显著降低数据库压力。
7. 开发中踩过的坑与给后来者的建议
7.1 弱网环境差点让项目翻车
最大的教训来自移动端。工厂车间多为钢结构，4G信号在角落非常差。最初设计是移动端发请求失败就弹"网络异常"，现场人员的反馈是"这系统根本没法用"。后来我把提交逻辑改成了本地暂存+批量同步：网络异常时巡检数据先存到浏览器localStorage，网络恢复后在后台自动补提交。这个改动让移动端可用性提升了一个量级。
7.2 时区坑：本地没问题，上线偏8小时
巡检记录表时间显示偏偏与实际时间差了8小时，排查一个下午才发现是JDBC连接串少了serverTimezone=Asia/Shanghai参数。这个问题本地调试时完全暴露不了，部署到服务器才出现，属于典型的"环境差异坑"。我的建议是统一使用DATETIME类型，同时在连接串里显式配好时区，别依赖服务器默认值。
7.3 多实例部署导致重复任务
项目后期打算做负载均衡，在预发布环境部署了两个后端实例，结果凌晨定时任务被触发两次，生成了重复巡检任务。排查过程还算顺利，因为重复任务的特征很明确——同一天同一个计划产生了两条任务。解决方案就是前面说的唯一索引+冲突跳过，一行SQL就解决了，但这个坑如果不提前预防，上线后数据会乱得不可收拾。
7.4 技术实现只是中点是业务价值才是终点
说实话，项目验收汇报的时候，领导根本不关心你用了什么框架、代码写得多优雅。他们关心的是：漏检率从之前的大概15%降到了多少？异常响应时间从几小时压缩到了几分钟？月度统计还需要人工汇总几天？所以我在统计模块专门做了一个数据大屏页面，把三个核心指标用图表直观呈现出来。效果非常好——管理层看大屏数据，现场人员用手机执行任务，系统的价值是看得见摸得着的。
7.5 开发顺序建议
如果大家要开发类似的系统，我建议按这个顺序推进：
- 先把"任务-记录-异常闭环"这条主链路跑通，不要一开始就铺开所有功能；
- 移动端体验优先于PC端功能，现场人员每天都在用手机；
- 统计口径务必提前和业务方确认，最怕开发完再改统计逻辑；
- 设计清晰的状态机，让状态流转受控；
- 权限和安全前置，不要在后期再补。
这套系统上线后，每天有几百个巡检任务在系统里流转，产生了上千条巡检记录，异常闭环率达到了预期水平。回想整个过程，最大的感悟是：这种系统的难点不在代码，而在把现场管理经验翻译成软件逻辑。每个企业的巡检规则都不一样，只有真正理解一线的作业方式，设计出来的系统才会被接受。
一次需求沟通会上，一位班组长直接跟我说"这个扫码太麻烦了"。我们后来在移动端加入了"连续检查"模式，允许在一个点位连续扫多个检查项，操作效率提升了一大截。这种来自一线的反馈比任何技术文档都有价值。如果你也在规划类似的系统，我的建议很简单：去现场待两天，把巡检员真实的工作流程记录下来，再打开编辑器写代码，做出来的东西完全不一样。技术方案都是现成的，难的是让系统真正贴合现场，让每个人都觉得它比原来的手工方式更方便。做到这一点，系统就成功了一大半。
