输电标准化作业平台这类项目，在电力行业里属于“看着不起眼、做起来极其磨人”的典型。几年前我带团队做某地区供电公司的运检信息化改造时，接手过一套编号55390的输电标准化作业平台源码，后来在这个基础上做了大量二次开发。这套平台的核心价值不在于界面多花哨，而在于把输电作业从“人管人”变成了“流程管人”。今天这篇不评技术高低，只讲这套平台到底解决了什么问题、代码结构有什么值得扒的地方、拿到源码后怎么跑通、怎么改，以及上线之后那些文档里不会写的坑。
1. 输电作业为什么非标准化不可：从一次夜巡事故说起
1.1 输电专业的作业类型到底有多杂
很多人以为输电就是“巡线”和“检修”两件事，真正做过运检的人才知道，输电专业的作业类型能列出一张长表。按规程级别和作业性质分，大致有：日常巡视（正常巡视、夜间巡视、特殊巡视）、带电检测（红外测温、紫外检测、杆塔接地电阻测试）、停电检修（绝缘子清扫、金具更换、杆塔螺栓紧固）、消缺处理（危急缺陷、严重缺陷、一般缺陷）、技改项目（杆塔改造、导线更换）、基建配合（新线路投运验收、交叉跨越测量）等等。
每一种作业类型对应的工作票模板、风险预控措施、标准化作业指导卡、验收标准都不一样。比如停电更换绝缘子，光作业步骤就能拆出二十多步，从停电申请、验电接地、登塔，到旧绝缘子脱开、新绝缘子安装、塔上检查、拆除接地线、恢复送电，每步都有卡控点。没有信息系统约束之前，这些步骤靠什么保证？靠工作负责人的记忆和纸质指导卡。人一忙、一累、一赶进度，漏步骤是早晚的事。
1.2 标准化之前：纸质单据和口头交接的混乱现场
我在该项目前期调研时，跟着班组跑过一次现场。当时的作业流程是这样的：前一天班长口头布置任务，工作负责人凭经验填一张纸质派工单，第二天到现场先开会宣读，然后开工。过程记录全靠一个夹在胳膊肘底下的笔记本，照片用手机拍完回去导进电脑，月底再人工汇总填报表。
这套传统流程至少有三个致命问题。第一，作业步骤是否被完整执行，事后根本无法验证，只能靠结果反推。第二，风险预控措施填写内容是否落实，没有闭环。老员工经验丰富能主动规避风险，新员工基本上是照着模板抄，写一套做一套。第三，过程数据和缺陷记录割裂，拍的照片、记录的隐患不能自动关联到杆塔台账，下一次巡线又得重新发现一遍同样的问题。
我们统计过，标准化平台上线前，某班组一个月的纸质作业记录归档齐全率只有六成左右，缺陷从发现到录入台账的平均滞后时间是3到5天。这个滞后带来的后果很直接——本应今天处理的危急缺陷，可能到第三天还在等人工录入。
1.3 标准化之后：流程、表单、数据的三重闭环
上平台之后，同样是那次夜巡任务，流程变成了这样：计划管理员在系统里建任务单，选择任务类型“夜间巡视”，系统自动绑定夜巡标准化作业卡（含危险点分析和预控措施模板），派给工作负责人。负责人用手机APP接单，按步骤逐项执行：到位签到（地理围栏校验）、每基杆塔拍照回传、发现缺陷现场选择缺陷类型和等级、提交验收。后端自动把缺陷记录写入杆塔台账，实时更新缺陷库。
这就是这套58390平台最核心的逻辑：整个过程由任务驱动，每个动作都有时间戳、照片、经纬度记录，表单自动生成，数据自动归档。标准化作业这两个字，体现在系统强制约束每一个步骤必须按卡控点走，不允许跳步。三年前我们上线到第四个变电站片区的时候，缺陷及时归档率已经能稳定在95%以上，这就是标准化的价值。
2. 平台核心业务模型：一张任务单如何走完生命周期
2.1 从计划源头说起：任务单是怎么生成的
拿到这套源码，啃业务部分的顺序建议从任务管理模块入手。我拆解了它的代码结构，发现整个业务模型的源头是“计划—任务—工单”三层。
年度检修计划和月度作业计划存在计划管理表里，计划条目包含任务类型、计划时间、工作内容简述、关联停电窗口。到了执行阶段，由计划生成任务单，这是整个平台业务链的主干。任务单上有几个关键字段：任务编号、任务类型、计划开始/结束时间、责任人（专职监护人）、工作班组、关联杆塔范围、关联设备台账ID。
这里有一个巧妙的设计：任务类型字段直接决定了后续所有联动逻辑。提交任务单保存时，后端会通过一个策略工厂查找该任务类型对应的标准化作业卡模板、风险预控库和表单模板。也就是说，同一个任务单实体，新建一个“停电登塔检查”的任务和新建一个“红外测温”的任务，进入作业执行界面时看到的步骤完全不一样。这个思路在代码里体现为一张“任务类型—模板绑定”的映射表，二次开发时新增作业类型主要就是往映射表里插数据，代码不需要大改。
2.2 作业步骤的卡控逻辑：为什么是状态机而不是审批流
平台里最核心的数据结构是“任务步骤节点”（task_step）。每个任务被分解成多个步骤，每个步骤有独立的开始时间、完成时间、操作人、检查人、附件列表和状态字段。它的状态流转不是简单的“待执行→已完成”，而是一个五态状态机：待开始（0）、执行中（1）、待审核（2）、已通过（3）、已驳回（4）。
状态机的意义我在二开时体会特别深。第一版我们图省事，用的是布尔字段is_finished，结果发现根本管不住流程。现场人员可以先把后面的步骤点了完成再回来补前面，整个卡控体系就形同虚设。后来改成状态机，只要上一步状态没有到达“已通过”，下一步的“开始执行”按钮就是灰的。这种强制约束才是标准化作业的真义。
状态流转的逻辑不复杂，大致是这样：工作负责人接单后，第一个步骤自动变为执行中；完成操作后点提交，状态切到待审核，同时系统给验收人推送审核消息；验收人审核通过，步骤状态变为已通过，解锁下一步。如果验收驳回，步骤状态回到执行中，并附带驳回原因，工作负责人重新操作后再提交。只有最后一个步骤通过，整张任务单才会进入“可归档”状态。
2.3 作业票证的电子化处理方式
输电作业绕不开安全规程要求的各类票证，平台上主要是停电检修工作票和电力线路第一种工作票。需要特别说明的是，平台并没有自创一套票证格式来代替现行规程，做的是把纸质票证电子化的映射：票面核心字段（工作地点、工作任务、安全措施、工作班成员、许可方式）做成表单，每一项对应数据库一个字段。
票证签发的流程在代码里体现比较清楚。工作负责人填写票证，交工作票签发人审核，签发人确认安全措施无误后电子签名，再交许可人进行许可操作（装设接地线、验电等确认操作后点许可），最后工作终结时再走终结确认。每一个环节都接了电子签名控件，签名图片落到独立的签名表，和票证主表通过外键关联。这样做的好处是打印时直接套用固定Word模板，把数据填充进去，签名图片按坐标插入，输出格式和原来纸质票完全一致，基层班组不会产生“系统又搞出一套新格式”的抵触情绪。
2.4 过程记录与归档：让数据可追溯比界面好看更重要
过程记录模块，也就是附件回传，是数据完整性的关键。实际作业中，现场照片往往一次任务拍几十张，手机相册里乱成一团。平台的处理方式是：每个步骤绑定一个附件桶，拍照后自动按“任务编号+步骤编号+时间戳”重命名，并同步写入照片的经纬度字段。
数据库里附件路径不能直接存相对路径或者文件名了事，要存绝对可访问的URL，且做好“冷热分离”。热数据（最近3个月）放在本机磁盘，冷数据定期归档到文件服务器或对象存储。我们二开时遇到的一个典型问题就是，现场人员用山寨浏览器打开日志附件，图片加载不出来，排查半天发现是附件URL写死成内网IP，在外网网络环境肯定访问不到。这个细节新手特别容易踩。
归档逻辑同样值得学习。任务单所有步骤完成后，系统自动把任务单、各步骤记录、票证、附件打包生成一个归档报告，同时更新相关杆塔台账的“最近作业日期”和“累计作业次数”。台账更新这个动作很容易漏，如果不做，作业数据沉淀不下来，后续统计就没有意义。
3. 技术选型逻辑：这个源码为什么不用微服务
3.1 选型前的三个问题：谁在用、多少并发、部署在哪
拿到源码后很多人第一反应是“这技术栈是不是太老了”。我理解这种心态，毕竟现在行业里张口就是微服务、容器化。但先别急着否定，选技术栈要看使用场景。这套平台的用户画像非常明确：一个地市级供电公司输电专业班组，人数一般几十人到百来人，同一时间在线操作的可能就二三十人，关键作业时段（比如集中检修季）会达到几百人同时在线的峰值，但这个峰值非常短暂。
部署环境更现实——生产环境往往在内网机房，有些甚至要求提供离线安装部署包，连外网都不通。这套平台选的技术栈是Java 8 + Spring Boot 2.x + MyBatis + MySQL 5.7/8.0 + Vue 2（前端），内置Tomcat，单体应用打一个Jar包就能跑。我觉得这个选型在对应场景下是合理且务实的。
3.2 单体架构加模块化拆分：比微服务更适合班组场景
为什么不搞微服务？很简单，这个平台的核心业务是强事务性的任务流，一个完整作业链路可能横跨任务管理、票证、步骤卡控、附件、台账五个模块，如果拆成五个微服务，一次任务提交就要做分布式事务，业务复杂度呈几何级增长，而用户量又远远达不到需要水平扩展的量级。
代码里采用的是模块化包结构，按业务域分包统一管理，比如按任务域、票证域、人员组织域、系统管理域划分层级。这样仓储都在同一个数据库里操作，跨模块调用就是本地方法调用，不需要网络请求，事务边界清晰，出错概率大幅降低。作为对比，我们同期另一套办公系统用的是微服务架构，部署需要注册中心、配置中心、网关、四个业务服务加一个前端，装一次环境要折腾掉一天，而那套系统的日活不过三百。这次教训让我之后做这类业务系统时，选型原则都固定下来：用户量没到几千、数据量没到百万级之前，单体永远是最优答案。
3.3 权限模型：基于用户角色权限的场景化设计
这个平台的权限设计属于经典的RBAC模型，但是实现上有一些值得借鉴的处理。用户和部门（班组）是多对多关系，用户通过角色获得权限点，权限点精确到操作级别。比如“可以创建任务单”是一个权限点，“可以审核任务单”是另一个权限点，一般操作员账号只有前者，班组长两者都有。关键敏感操作（终止任务、驳回、删除任务）的角色绑定了额外的数据权限——必须且只能在本人所属班组的数据范围内操作，这是通过SQL中强制拼接部门ID条件实现的，而不是靠前端按钮隐藏来防误操作。
权限这块还有一个容易踩的坑：前端菜单展示和后端接口鉴权必须分开做。这套源码在前端路由里做了菜单级别控制，但后端每个接口方法都加了权限注解，两者缺一不可。如果不理解这个设计，二开时新增一个接口只写了前端判断，别人直接调用这个接口就能绕过权限，那问题就严重了。我见过某个被二次开发过的系统就出过这种事，排查时发现后端完全没有校验逻辑。
4. 源码部署与二次开发：从跑通到改造全流程
4.1 环境准备：离线还是在线，先想清楚
源码运行的步骤不算复杂，但有几个前置条件很关键。JDK要求1.8及以上，MySQL建议5.7或8.0，前端用Node 14或16版本，后端是标准的Maven工程。
我第一次部署时是按在线环境装的，顺序是：安装MySQL，执行建库脚本；导入初始数据脚本（包含所有菜单、权限点、角色、示例用户和几种常用作业类型的作业卡模板）；用命令行启动后端Jar包；前端执行打包。
在线装容易，离线环境才是真正的考验。内网机器不能联网，Maven没法从中央仓库拉依赖，Node也装不了npm包。这里给一个省事方案：在一台能联网的机器上，把后端的整个本地仓库目录（路径一般是用户主目录下的.m2/repository）打包，拷到内网机器解压到相同路径；前端呢，开发环境跑的话直接拷node_modules目录，构建环境则直接拷打包后的dist目录。离线部署时这里有一个常见的坑：本地仓库路径被写死在Maven的settings.xml里，换个用户名解压后路径变了，启动时各种找不到依赖的报错。解决办法是修改settings.xml里的localRepository路径，保持和仓库包实际存放位置一致。
4.2 数据库初始化：先看这张表，能少走一半弯路
脚本导入之后，建议不要急着登录系统，先打开数据库看两张表：一张是“任务类型—作业卡模板绑定表”（业内一般叫task_type_template），另一张是“菜单表”。
这两张表是理解整个系统的钥匙。任务类型表决定了作业卡如何联动，菜单表则决定登录后能看到哪些功能。修改菜单的一个经典坑是：菜单表中“是否显示”字段直接决定前端侧边栏出现与否，但隐藏菜单对应的路由仍可直接通过URL访问。所以隐藏菜单不能当作权限控制手段，只能当作界面清理工具，真正的权限控制要去“角色—权限点关联表”里操作。
另外，如果你拿到的是这套源码的初始版本，初始化数据里通常只有“停电消缺”和“正常巡视”两个任务类型的模板。导入数据后建议逐字段检查一遍这两个模板的步骤顺序对不对，再做业务测试，不然直接影响后续验证效果。
4.3 新增作业类型：一张模板加两行配置的完整演示
理解了上述结构，二次开发最基础的需求——新增一种作业类型——就非常简单了。例如我们要加一个“复合绝缘子憎水性测试”任务类型，步骤如下：
第一步，在任务类型表添加一条记录，类型编码取一个唯一值。 第二步，在“作业卡模板表”添加该类型对应的步骤节点，每个节点包含节点名称、排序号、是否必须回传照片、危险点分析和预控措施文本。 第三步，在任务类型—模板绑定表插入关联记录，绑定两者。 第四步，测试：新建任务时选择新类型，查看作业执行界面是否按模板步骤展示。
第二步操作时要注意一个细节：步骤节点里“是否必须照片”字段如果置为1，那么现场人员提交该步骤时，系统会校验最近上传的照片数量为零时禁止提交。这会强制记录作业过程，但也会导致作业人员因为手机信号不好、照片传不上去而卡在步骤里。我二开的经验是，核心安全步骤（验电、接地、登塔）照片设为必须，其余步骤设为可选，最终验收时再由工作负责人集中批量补充照片。这套折中方案在真实班组使用中反馈很好。
4.4 值得反复研究的核心逻辑代码
源码里有三个地方值得抽出来仔细看。第一个是任务单创建的后端方法，覆盖了任务单字段初始化、根据任务类型自动绑定流程模板的逻辑，以及消息推送。第二个是任务步骤提交与审核的后端方法，这里实现的是状态流转的完整校验，包含当前状态判断、下一步解锁、时间戳记录、日志留存。第三个是打印功能对应的工具类，实现了数据填充和格式控制的关键逻辑。
这三个方法吃透后，整个平台的骨架就通了。其余模块如公告、通讯录、系统设置都属于外围功能，不用深究。
5. 实际部署上线后，我踩过的坑和调整
5.1 内网离线安装时的依赖包倒腾
离线环境导入本地仓库，我前面提过路径问题，但还有更隐蔽的坑。平台前端用的构建工具在打包时会检查某些依赖包的版本签名，版本对不上直接构建失败。为了省事，我们当时直接在有网环境下把构建产物文件夹整体拷到内网机器，再配Nginx指到静态目录，绕开了在离线环境里构建的麻烦。后端则直接拷贝一个可运行的Jar包，用启动参数指定配置。这种方式虽然不够优雅，但确实是最稳妥的。
5.2 作业指导书打印乱码问题
打印模块的乱码属于高频问题。这类平台输出作业指导书时用的是Word模板填充方案，模板字段用占位符标记，后端按映射表替换。如果占位符字段名和模板里的引用名不一致，替换后会出现整段空白或显示异常。更常见的乱码原因是后端服务运行的操作系统缺少中文字体，导致生成时字体缺失。排查手工流程要围绕字体配置选项做检查；如果基础字库缺失，可以添加开源中文字体到系统的字体目录并重建字体缓存，通常可以解决。
5.3 角色权限配置引发的“幽灵审批”
正式上线后曾被检修班反馈了一个“幽灵审批”的诡异问题。某个副班长账号明明没有被赋予审批权限，但点提交却可以审批通过。排查链路是：先看角色权限关联是否写死，再看账号是否通过部门继承拿到了角色。原来这套源码的用户组织模型里有“继承权限”开关，副班长所在的部门角色树中，上级角色拥有审批权限，且默认勾选了向子级继承。权限树是隐性继承的，界面上很好维护，但也极易误用。整改方案是在所有部门节点上关闭二开时默认勾选的继承开关，所有权限改为显式授权，并逐个角色做了核验。
这个问题的价值在于，它说明了权限模型不能只靠阅读代码来判断，必须配合角色继承树做全链路排查。任何部署上线前的验收都必须包含权限矩阵测试——建立“角色×操作”矩阵，逐项过一遍预期结果和实际结果的对比。
5.4 移动端真机适配的粗糙方案
平台有移动端APP，但源码里的移动端布局适配做得比较粗糙。现场作业人员用的安卓手机型号五花八门、分辨率差异大，测试时发现华为、小米、OPPO等设备显示都正常，但个别机型会出现按钮溢出和表格横向滚动失效的问题。我这里分享一套处理过的方案：不要试图在系统里做全面响应式重构，而是调整列表页的卡片化和表单页的安全间距适配，即按钮加大点击区域、表格列最小宽度显式设定、图片压缩比例与质量分开控制。这套“最省力的尽力适配”方案上线后，设备适配问题基本没有再被班组投诉过。
最后说点实在的
这套编号55390的输电标准化作业平台，单论技术难度不算高，但它把一个长期靠制度约束但缺少工具支撑的业务场景，真正落成了可执行、可追踪、可考核的系统。我最大的体会是，这类业务系统的二次开发，业务理解永远比技术炫技重要。拿到源码第一步不该是急着改界面，而是先吃透业务表结构和状态流转逻辑；真正体现价值的功能，往往是那些让一线人员少做一步、少记一件事的小改动。这批代码后来被我反复参考，成为后续做电力运检类项目的基础底座，常看常新，也推荐给正在做这类平台的朋友。
