从事电力行业的系统开发，和做互联网业务系统完全是两回事。电网现场的设备台账、配网故障抢修、巡检工单流转，每一块业务都牵扯着真实的生产安全和供电可靠性。这几年我先后参与过两个电力行业的Spring Boot项目，一个偏生产管理，一个偏设备数据采集，从需求调研到生产环境跑稳，中间踩过的坑、总结出的规律，比写业务代码本身要值钱得多。这篇文章就把这条完整的落地链路拆开讲清楚：怎么做需求调研、怎么选技术栈、核心模块怎么写、生产部署有哪些文档里不会写的细节。
先说一个很多人容易忽略的前提：电力行业的软件项目，真正的难点从来不是技术，而是理解业务。你面对的客户可能是一线运维班组，可能是调度中心的技术专责，也可能是物资管理人员，每个人的诉求差异极大。如果调研阶段偷懒，后面所有设计都会被推翻重来，这个代价比多花一个月做需求分析要惨痛得多。
1. 先搞懂电力业务再说开发：需求调研与边界划定
1.1 电力行业系统的分类与典型痛点
电力行业的软件系统按业务属性大致可以分成几类：生产管理系统、营销计费系统、调度自动化系统、设备状态监测系统，以及现在很热的企业经营管理和办公协同类系统。不同系统的技术要求和团队构成完全不同。调度自动化对实时性和可靠性要求极高，通常采用专用软硬件方案；营销计费涉及海量用户数据和复杂的电价规则；而我们这类基于Spring Boot开发的项目，往往落在生产管理、设备管理、数据采集与展示这些偏业务管理的场景。
这类系统的典型痛点有几个。一是数据分散，设备台账可能在多个Excel表和旧系统里并存，同一个变电站的变压器参数在不同科室统计口径都不一样。二是业务流程存在大量线下环节，比如巡检发现缺陷后，班组填写纸质工单，再走OA流程审批，效率低且过程不透明。三是现场网络环境复杂，变电站、开闭所这些位置可能只有内网，甚至部分偏远站点网络并不稳定，系统设计时必须考虑离线或断网续传场景。四是历史包袱重，客户的习惯被老系统固化，你设计的新交互哪怕再合理，也可能被"我们之前不是这么做的"挡回来。
1.2 需求调研的实操方法：现场跟班与数据流梳理
我在电力项目里最有效的需求获取方式，不是开会，是跟班。第一次做变电站巡检系统时，我跟着运维班组走了一整天现场。早上八点半开站班会分任务，每人拿一张纸质的巡视卡，上面列着上百个检查项，从变压器油温油位到端子箱封堵情况，逐项打钩。回来后把巡视结果一条条录入电脑，再形成缺陷记录。这一趟让我彻底理解了"巡视卡为什么这么设计"，也看清了数据从现场到系统的全路径。
具体操作上，我会用三步法做需求梳理。第一步是画出完整的业务数据流：从原始数据产生（现场巡检、设备遥测、人工上报）到中间处理（审核、归档、统计分析），再到最终输出（报表、大屏、工单指令）。第二步是针对每个环节问三个问题：这个数据现在存在哪里？谁负责维护？谁需要看这个数据的结果？第三步是把客户口中的"需求"回译成"业务规则"，比如客户说"缺陷要能及时处理"，那就要明确"及时"是多久，超时之后的升级机制是什么，哪些角色能催办，催办方式是什么。这些细化之后才能转化成可落地的功能点和验收标准。
1.3 边界划定：哪些功能必须做，哪些该砍掉
电力行业项目特别容易需求失控，原因是干系人太多。分管领导想要大屏展示，生产部门想要工单闭环，班组想要移动端录入，信通部门要求统一权限接入，每方都提出合理性极高的需求，但项目资源和工期是有限的。我在立项阶段会主动做一轮"需求砍价"。
我习惯把所有需求按两个维度分类：业务价值高低、技术实现成本高低。高价值低成本的需求直接排入一期；高价值高成本的拆解优先级，分阶段交付；低价值低成本的合并处理；低价值高成本的一律延后。这个过程中最难的是说服客户放弃一些"锦上添花"的功能，我的做法是把每个需求对应的业务场景讲透，让客户自己判断投入产出比。比如客户提过"每个设备都要做三维模型展示"，但实际使用场景只是看参数和状态，二维列表加图表完全够用，三维模型开发成本高、数据维护难度大，砍掉后客户实际使用阶段也没觉得缺失。
边界划定还有一层意思是技术边界。要明确哪些数据从外部系统同步，哪些数据由本系统维护；哪些操作需要对接现有的统一权限平台，哪些在本系统内管理。我的习惯是把这些边界画成一张系统交互图，标明数据流向、接口协议和职责归属，哪怕这张图只有自己能看懂，也能在后续扯皮时作为依据。
2. Spring Boot选型组合：稳定大于新颖，兼容重于炫技
2.1 版本选择的逻辑：企业级项目为什么不用最新版
Spring Boot版本选型这件事，网上教程很多，但企业级项目的逻辑和自学项目完全不同。电力行业客户的生产环境经常还跑着老版本的操作系统、数据库、JDK，这些问题在开发环境根本不会暴露，等到部署时才炸出来。
我的选型原则是：在满足功能前提下，选择经过市场验证的成熟版本，不追新。举个例子，Spring Boot 2.3.x到2.6.x这个区间里，2.6.x对配置文件的处理机制有调整，如果你从早期版本升级，一些自定义配置可能失效。如果项目涉及大量XML配置或依赖第三方组件的旧版API，贸然上2.6以上版本会给自己挖坑。
我个人在实际项目里，JDK 8是绝对的主力选择，对应Spring Boot 2.x系列。不只是因为客户环境大多能跑JDK 8，更关键的是项目里可能要用到的很多中间件、SDK，在JDK 8上的兼容性问题最少。Java 17和Spring Boot 3.x确实是趋势，Spring官方也在大力推进，但现实是很多电力行业的第三方组件、内网依赖仓库还停留在旧版本生态，强行上新版本反而增加适配成本。
另外一定要确认客户的部署环境。有的项目部署在内网服务器，无法访问外网Maven仓库，这就得提前把依赖包全部打包好，或者在内网搭建私有仓库。有个项目我接手时发现他们还在用JDK 7，那Spring Boot版本就得降到1.x系，这种兼容性约束必须在技术方案评审时就说清楚。
2.2 配套组件选型：数据库、缓存、消息队列的取舍
底部技术栈的配套选型，我习惯于先用一张表把需求和备选方案列出，再逐一收敛。
以我负责过的设备状态监测系统为例。数据源是遍布各站点上传的设备运行数据，单日写入量在数十万条量级，查询场景多为按时间段、设备维度做聚合统计。数据库选了MySQL 8.x，数据分库分表，按站点和月份做分区；缓存层选了Redis，存放设备实时状态、热点数据、用户会话；消息队列选了RabbitMQ，用于数据接入时的削峰和模块间解耦。
选择MySQL而不是PostgreSQL或Oracle，主要考虑的是团队熟悉度和生态兼容性，电力行业旧系统里Oracle很多，但项目接手的团队大多对MySQL更轻车熟路。分区表是处理时序数据的一个好帮手，比如按月份RANGE分区，查询时自动分区裁剪，避免全表扫描。在数据量达到千万级时，配合索引和SQL优化，性能依然可控。
Redis的使用要看场景。设备总览页需要展示几百台设备的实时状态，如果每次都查MySQL，压力很大。我把设备最新状态放Redis，更新时直接写缓存，定时任务做持久化。注意要设置合理的过期时间和淘汰策略，避免缓存和数据库数据不一致。项目中我用的是Spring Data Redis，封装好RedisTemplate工具类，统一处理序列化问题。
消息队列是另外一个重点。电力系统的数据接入往往是突发性的，采集终端同时上报会造成数据库连接打满。我习惯在数据接入服务和服务层之间加一层RabbitMQ，上报数据先入队，消费端按数据库能承受的速率拉取写入。这种模式对实时性稍有损失，但稳定性大幅提升。队列消息的幂等处理一定要做，因为消费者可能异常重启，消息重投会导致重复数据处理。我常用消息唯一ID加Redis分布式锁做去重，简单有效。
2.3 多人协作下的工程结构规划
电力行业项目的开发团队规模通常在5-10人之间，工程结构的规划直接影响协作效率。我不推荐一张大而全的单体工程，也不建议上来就拆微服务，更合理的做法是模块化单体加扩展边界。
所谓模块化单体，就是在一个Spring Boot应用内，按业务域划分模块，类似Maven多模块结构。比如设备管理模块、工单模块、数据采集模块、系统管理模块，每个模块有独立的Service、Controller、Mapper包路径，依赖关系用Maven管理，模块间通过接口交互，避免循环依赖。好处是开发和部署简单，一个应用包跑所有功能，同时业务边界清晰，后续如果某个模块要拆成独立服务也有基础。
微服务不是不能选，但电力行业的很多业务系统用户量并不大，核心诉求是稳定和易维护，微服务带来的分布式事务、链路追踪、运维复杂度，在这个体量下是负担而不是价值。如果确实有独立部署、独立伸缩的需求，我建议先把模块边界做好，按需拆分，而不是一开始就上Spring Cloud全家桶。
在工程结构上，还有几个细节值得注意。一个是统一的结果返回体，所有接口返回相同结构的JSON，包含状态码、消息、数据体，前端处理逻辑统一。第二个是全局异常处理，通过@ControllerAdvice统一捕获业务异常和系统异常，避免异常堆栈直接暴露给前端。第三个是参数校验，统一使用JSR-303注解加全局校验异常处理，而不是每个接口手动写校验代码。这三件事看起来琐碎，但对后期维护的帮助极大。
3. 核心业务模块开发实录
3.1 设备台账模块：表结构设计与数据治理
设备台账是电力行业系统的地基，几乎所有功能都依赖设备数据的完整性和准确性。我刚做第一个项目时低估了这个模块的工作量，以为就是一张设备表加增删改查，后来才发现设备台账涉及的数据维度极其复杂。
以变电站的设备台账为例，层级关系是"变电站-电压等级-设备间隔-设备本体-附属部件"。变压器本体下有分接开关、冷却器、油枕等附属设备；断路器有操作机构、灭弧室等组成部分。每个设备类型又有不同的参数项，油浸式变压器要记录油温、油位、油耐压值，GIS设备要记录SF6气体压力。这种多层级、多类型的结构，一张平铺表根本搞不定。
我的设计思路是采用"主设备表+扩展属性表"的方式。主设备表存公共字段：设备编码、设备名称、所属站点、电压等级、设备类型、生产厂家、投运日期、状态等。扩展属性表以JSON字段存储不同设备类型的特有参数，利用MySQL的JSON类型加虚拟列索引，既能灵活扩展，又不影响查询性能。为了兼容老系统的编码规则，设备编码字段单独建唯一索引，并在导入时做好幂等校验，重复导入不产生脏数据。
数据治理是这个模块的重头戏。电力行业的老数据质量普遍一般，同一个设备在系统A叫"1号主变"，在系统B叫"1号变压器"，导入新系统时必须统一映射规则。我在项目里专门开发了数据清洗工具，先按站点和电压等级建立基础字典，再通过规则匹配和人工确认两步完成历史数据导入。这个阶段一定要让业务科室深度参与，他们最清楚老数据里的"坑"在哪。
3.2 工单流转：状态机建模与并发控制
工单管理是电力生产管理系统中最典型的业务模块，涵盖巡检工单、缺陷工单、抢修工单、操作票工作票等多种类型。这些工单的共同特点是状态多、环节多、涉及角色多，如果不做好的建模，代码很快会被各种if else塞满。
我处理工单模块的核心方法是状态机建模。先梳理业务规则，把工单的完整生命周期抽象成有限个状态，再定义状态之间的合法迁移路径。以缺陷工单为例：待派发、已派发、处理中、待验收、已归档，外加挂起和驳回两个异常状态。每个状态迁移都对应一个业务动作，比如"派发"是从待派发到已派发，"申请挂起"是从处理中到挂起。我把这张状态机表画出来后，让业务人员确认，确认无误后再写代码实现。
实现层面，我在项目里用了一个简洁的组合方式：Spring状态机可用，但很多场景下控制反转太重。我更倾向于用枚举加状态迁移校验表的方式，把当前状态和期望目标状态传入校验器，合法则执行动作并更新状态。这样逻辑清晰，也方便写单元测试。状态变更记录一定要完整落库，也就是常说的流水表，否则后期排查问题时拿不到证据。
并发控制是工单模块里容易被忽略的问题。举个例子，两个班组长同时对同一张工单操作，一个派单给A班组，一个派单给B班组，如果不加控制，最终状态就会错乱。我的做法是更新时带上乐观锁版本号，update语句里加上state和version两个条件，更新行数为0则说明状态已被别人改过，业务层抛出冲突异常由前端提示用户刷新重试。这种方案在工单这种低并发场景下完全够用，没必要上分布式锁。
3.3 数据采集与展示：从时序数据到可视化大屏
电力行业系统的数据采集和展示，最常用的是两类技术组合：WebSocket做实时推送，ECharts做可视化图表。Spring Boot集成WebSocket时有一个经典配置点：在application.yml里。
spring: websocket: # 按需配置，主要是自定义握手和各端点的映射细节配置本身并不复杂，真正容易踩坑的是WebSocket服务的集群化问题。默认的WebSocket会话保存在单机内存里，一旦部署多实例，用户连接的是A机器，消息从B机器发过来就推送不到。我在项目里用Redis发布订阅模式解决了这个问题：所有实例订阅同一个频道，发布消息时广播到频道，各实例收到后向自己维护的会话推送。这套方案在几百个连接的规模下非常稳定，和引入一套MQTT或专门的消息推送中间件相比，成本低得多。
时序数据的展示要特别注意聚合查询的复杂度。设备状态监测系统接入后，前端大屏需要展示电压、电流、温度等遥测数据的实时曲线和历史曲线。实时数据走WebSocket推送，历史数据走RESTful接口查询。历史曲线如果直接从明细表查询几十万条记录再渲染，前端会卡死，响应时间也过不了性能测试。正确的做法是预聚合，按不同时间粒度建汇总表，5分钟聚合、1小时聚合、1天聚合各建一张，前端按时间范围选择对应粒度的表。这个思路可以套用在不同项目中，本质是用存储换查询速度。
可视化大屏这块，ECharts依然是主力。开发时有两个经验值得分享：一是大屏数据不要由前端定时轮询后端，而是后端推送，前端做增量更新，这样体验最流畅；二是大屏管理页面要做好按角色配置，不同领导看的指标侧重点不同，设计成可拖拽配置的看板比写死一组图表更受欢迎。
3.4 用户权限与操作日志：内控要求下的两个硬指标
电力行业对系统的安全审计要求比普通企业高，权限管理和操作日志是评审时必查的两个功能。
权限模型我采用经典RBAC：用户-角色-权限三级结构，外加数据权限维度。数据权限这一点容易被忽略，举个例子，某个地市分公司的账号只能看到自己分公司管辖的设备台账，省公司的账号则可以看到全省数据。实现上我通常用组织架构作为数据权限的基础，所有业务表带上org_id字段，查询时自动拼上当前用户可见的组织范围。这个规则要在MyBatis层做统一处理，比如自定义拦截器自动追加数据权限SQL条件，而不是每个Mapper方法手写。
操作日志要区分两种：一种是对关键业务数据的操作审计，比如设备信息修改、工单派发、删除文件，这类日志需要记录操作用户、操作时间、操作前后的数据快照、来源IP；另一种是系统运行日志，可以交给Logback按天滚动。审计日志建议独立表存储，数据量上来后按季度归档。这里有一个小细节：修改前后的数据快照建议用JSON序列化存MEDIUMTEXT字段，方便后续审计追溯，又不用为每个业务表建历史表。
分布式系统开发在这个环节要特别注意：如果项目已经拆了多个服务，日志链路追踪建议引入TraceId，在网关或统一入口生成，通过MDC传递到日志输出。我在模块化单体项目里也这样做了，排错效率很高。
4. 生产落地：那些文档里不会写的部署细节与运维经验
4.1 部署架构：从单机到集群的演进路径
电力行业系统的部署环境千差万别，有的是信通部门统一管理的虚拟机，有的甚至还是物理机，所以不要默认你的应用一定能跑在Kubernetes上。我的经验是先问清楚客户现有运维能力和基础设施，再设计部署方案。
大部分项目建设初期，一台应用服务器加一台数据库服务器的部署就够用了。Spring Boot打成一个可执行jar包，配好Nginx做反向代理和静态资源服务，数据库单独跑在一台机器上。这里要提醒一个细节：Spring Boot默认的内嵌Tomcat在生产环境需要调优，包括最大线程数、最大连接数、acceptCount、连接超时等。配置在application.yml里，不同业务场景参数不同，设备数据上报类应用数据写入压力大，线程数可以调高一些；报表查询类则要看数据库连接池的配合。生产配置里还建议显式配置线程池的各项参数，避免默认值造成性能瓶颈。
当业务量上来或对可用性要求提高后，最朴素的演进方式是应用双节点部署，前面加一层Nginx负载均衡。Spring Boot应用是无状态的，会话可以通过Redis共享，这样任意一台机器宕机，另一台还能扛住。这种架构对团队运维能力要求不高，也不需要额外引入注册中心，非常适合电力行业的中小型业务系统。
内网部署还有一个常见问题：服务器无法访问外网，Maven依赖、yum源都不可用。我的做法是在开发环境把依赖包统一导出，部署时连同安装介质一起带到内网，提前把Redis、RabbitMQ这些中间件的离线安装包也准备好。这个准备工作要在联调阶段就做完，别等到上线前一天。
4.2 监控与日志：故障快速定位的必备手段
系统一旦跑在生产环境，监控和日志就是保命手段。电力行业的系统出故障，影响面可能是一大片供电所，必须做到快速发现、快速定位、快速恢复。
监控层面我建议分三层。第一层是基础监控，CPU、内存、磁盘、网络这些用Prometheus加node-exporter就能搞定，服务器指标做到标准化采集。第二层是应用监控，Spring Boot Actuator是标配，暴露health、metrics、logfile等端点，配合Micrometer把JVM指标、Tomcat连接数、线程池状态等接入Prometheus。第三层是业务监控，关键业务指标比如今日上报数据量、工单未处理数量、采集终端离线率，可以在应用里埋点，定时上报到监控系统，设置告警阈值。这里我要特别强调JVM监控的重要性，之前有一次生产故障就是线程池耗尽，如果早看到JVM线程数的监控曲线，能在故障发生前就处理掉。
日志这块要制定规范：统一日志格式，包含时间戳、TraceId、类名、方法名、日志级别、业务消息。我在项目里用Logback的PatternLayout统一格式，并按天滚动、按大小触发归档，保留最近30天日志。排查问题时，我先通过TraceId在日志里串起一条完整调用链，再定位具体是哪个环节出了问题，效率比直接搜关键词高得多。
4.3 一次真实的故障复盘：线程池耗尽问题
分享一个我真实遇到过的生产故障。某次系统上线后运行了大概三周，突然监控报警，接口响应超时比例明显上升。登录服务器一看，Tomcat线程数打满，连接池等待任务大量堆积。起初怀疑是突发流量，但看了监控曲线发现流量并没有明显上涨，这个现象很不符合常理。
排查过程大致如下。第一步看线程dump，发现大量线程阻塞在等待数据库连接池获取连接上，初步判断是数据库连接池被耗尽。第二步看数据库侧，活跃连接数确实很多，且大量SQL是同一个查询模板，执行时间1秒以上。第三步看SQL执行计划，发现这个查询关联了多张表且有一个条件字段没走索引，数据量上来后全表扫描导致慢SQL拖慢整个连接池。
根因找到了：新的查询需求在迭代中加了数据权限过滤条件，但还没建好对应的联合索引，上线后查询走了全表扫描。而慢SQL本身不致命，致命的是慢SQL占据了池里的连接，导致其他正常业务拿不到连接，形成雪崩效应。修复方案分两步，第一步快速止血，杀掉占用连接的慢SQL并把相关查询路由到只读库，恢复服务；第二步是优化SQL、建立联合索引、设置连接池超时和熔断机制。这个案例给我的教训是：生产环境的故障不一定来自并发量飙升，慢SQL和资源池耗尽才是最常见的隐形杀手。
4.4 性能优化与容量规划：提前把底子打好
做完故障复盘，我想专门聊一下性能和容量这两件事。很多开发者开发阶段不注意性能，总想着上线后优化，但电力行业的系统一旦上线，整改窗口非常少，业务部门不会给你那么多时间慢慢调优。
数据库层面要有几个习惯。第一，所有核心查询建立合适的联合索引，尤其要注意条件顺序，最左前缀原则要遵守。第二，避免select *，只取需要的列。第三，大表的统计查询要离线预聚合，实时查明细表在数据量大时必挂。第四，事务要短平快，不要在事务里做远程调用、循环查询或复杂的计算逻辑。
缓存层面要选准使用场景。Spring Boot项目里引入Caffeine成本极低，本地缓存适合放配置类数据、字典表这类变化少的静态数据，配合@Cacheable注解使用非常方便。Redis缓存适合存放需要跨实例共享的数据，比如设备最新状态、用户会话、分布式锁。我在一个项目里用Caffeine缓存设备型号参数，这些数据一天变不了几次，命中率98%以上，有效缓解了数据库读压力。
容量规划这一块，不多想一步就会出问题。比如估算设备采集数据量时，要考虑未来三年的接入终端增长，而不是只看现在的数。我在设计分表策略时通常按年预估，留出冗余空间。类似的消息队列堆积能力、日志磁盘占用、数据库连接数规划，都要在架构评审时给出明确的数字依据，不能一句"后面再说"带过。
5. 电力行业项目管理的几个隐性经验
5.1 与业务人员的沟通节奏和验收口径
技术问题聊完了，说几个项目管理层面的经验，这些往往决定项目成败。
电力行业的客户业务人员非常忙，生产任务重，不能指望他们像互联网产品经理一样随时配合你。我的做法是提前预约需求确认会议，并把自己整理好的业务规则文档提前发给他们审阅，会上只确认有分歧的点。同时约定每周一个固定时间做阶段评审，避免需求理解偏差累积到后期集中爆发。
验收口径要在项目开始时就和客户对齐。比如工单模块的验收标准是什么，是页面能用就算过，还是需要按设定的状态流向完整跑通一遍，再叠加异常场景验证。我在需求阶段就整理出一份业务场景清单和对应的验收用例，让客户签字确认，这样到验收阶段双方都按同一份标准执行，减少扯皮。
5.2 电力行业数据安全与内网部署的特殊约束
电力行业对数据安全有专门的管理规范，这一点在技术方案阶段就要考虑。系统部署通常在内网，极少直接暴露在公网，对外访问要经过统一的安全设备。数据库密码、中间件认证信息这些敏感配置，不能硬编码在配置文件里，更不应该提交到代码仓库。我在项目里使用Jasypt对配置文件中的敏感字段加密，启动时通过环境变量传入解密密钥，这样即使有人拿到配置文件也无法直接使用数据库账号。
代码交付时还要注意来源合规。电力行业的客户通常会要求做漏洞扫描和安全测试，部署前把生产依赖版本过一遍，有已知高危漏洞的组件提前升级。Spring Boot的依赖版本管理本身会锁定一套兼容版本，但如果项目里另加了其他第三方组件，也要一并检查。
5.3 这类项目后续扩展的三个方向
项目交付不是终点，而是运维和扩展的起点。根据我的观察，电力行业基于Spring Boot的项目后续常见的扩展方向有这么几个。
第一个是移动化。一线运维人员基本都在现场作业，电脑端系统的使用场景受限制。如果项目初期就把后端接口设计成RESTful风格，后续输出一份接口文档，开发安卓或鸿蒙端就顺利得多，不需要改造后端。
第二个是业务流程自动化和智能化。比如缺陷工单的分派目前依赖人工判断，后续可以引入规则引擎或算法推荐，按班组工作量、技能标签自动推荐处理人。这类功能在技术架构上利用现有Spring Boot服务加一个决策模块即可，不需要推翻重来。
第三个是与新型技术的融合。电力行业这两年在设备巡检、故障预测、负荷预测这些方向大量引入智能算法。Spring Boot服务作为算法模型的部署载体非常合适，通过Python服务封装算法接口，再让Spring Boot通过HTTP或消息队列调用，形成完整的预测-决策-执行链路。这个方向对系统架构的扩展性有要求，所以前期模块边界梳理得清不清楚特别重要。
我在实际项目中还有一个体会：电力行业的系统上线后，真正让客户认可你的，往往不是上线发布会上的那些功能演示，而是日常运维中你的响应速度和解决问题的能力。我手头一直维护着一份部署手册，记录服务器的登录方式、各节点的启动顺
