尧图网站建设 
简介基于Spring Boot的电费征缴系统EMS是一份面向Java学习者与电力行业信息化开发者的完整项目源码重点演示企业级Web系统从用户管理、电费计算到在线缴费、报表统计的落地实现。压缩包内共23个文件包含16个Java源文件、Maven构建配置、项目说明文档及运行辅助脚本整体大小仅19KB适合快速读懂核心代码结构。已有273人学习访问资源以Maven标准工程组织通过Spring Data JPA、Spring Security等典型组件展示后端服务、安全控制与支付集成的常用写法读者可据此梳理业务模块划分并参考README完成本地环境搭建与二次开发。 EMS在快递行业是那个邮政特快专递但在用电管理圈子里它指的是Electricity Management System——电费征缴管理系统。我这个项目就是一套跑在Spring Boot 3.2之上的电费征缴系统核心解决的是那种“物业/园区/转供电主体手里一堆电表却还在用Excel算费、微信催缴、手工登记”的老大难问题。如果你正在给学校、产业园区、商业综合体或者工厂做能耗计费和收费管理这篇实践记录会很有参考价值。这类系统表面上就是一个计费加收钱的小工具但真正拆开做之后你会发现坑全藏在“电费规则怎么配置”“账单状态怎么流转”“金额怎么保证一分不差”这些细节里。这套系统我从数据库建模到接口联调、再到后续和支付通道对接前后花了差不多三周踩了不少坑也沉淀了一些通用做法下面把整个项目的核心设计和关键代码完整记录一遍。1. 项目初衷与整体设计思路1.1 为什么叫“EMS”而不是普通的“缴费系统”很多人在第一次听到“EMS”的时候首先想到的是邮政快递但在能源管理这个具体场景里EMS的含义更偏向“管理”而非单纯“收费”。传统的电费管理流程是人工抄表、手工算费、线下催缴数据散落在纸面和Excel里到了对账的时候非常痛苦。我做的这套EMS系统从一开始就把“管理”放在了“收费”前面也就是先管住设备、管住读数、管住费率最后才是收钱。也因此系统被拆成了几个大的业务域基础档案域管用户和电表计量域管抄表数据和异常读数计费域管费率计算和账单生成结算域管缴费和对账。每个域之间通过数据库表结构和领域服务解耦互相不越界这对于后续要扩展预付费、阶梯电价、分时电价这些能力会非常关键。1.2 技术栈选型Spring Boot 3.x MyBatis-Plus MySQL技术选型没有太多花哨的东西就是当前Java后端最主流的一套组合。Spring Boot选了3.2.x版本JDK 17因为Spring Boot 3.x是基于Jakarta EE命名空间相比2.x性能更好、生态也在快速迁移。MyBatis-Plus做持久层不是为了复杂的SQL生成而是看中它的分页插件和LambdaQueryWrapper能让业务代码干净不少。数据库用的MySQL 8.0存储引擎InnoDB字符集utf8mb4排序规则utf8mb4_general_ci——这里有个小细节值得留意电费系统里会出现业主名称这类中文数据如果排序规则没选对后续like查询可能遇到乱码或索引失效的问题。支付模块对接的是通用的微信支付Native下单之所以没有做支付宝是因为实际项目里物业方和园区方的诉求高度一致租户或业主扫码就能付后台能看到每一笔回调结果。用Native支付的好处是后端不感知前端扫码环境只需要返回一个二维码链接前端自绘二维码即可联调成本很低。1.3 架构上的“三独立”原则这套EMS在设计上我给自己定了一个“三独立”原则费率独立、账单独立、流水独立。费率独立指的是费率表不直接绑定到账单上而是通过版本号和时间段去关联这样电价调整的时候历史账单不受影响。账单独立是指一条账单记录只属于一个计费周期不允许跨周期合并哪怕某个租户两个月都没交费也必须生成两张账单方便后续滞纳金计算和财务核销。流水独立则是指每一笔支付回调、每一笔退款、每一笔手工调整都必须落到流水表里账单金额只是结果流水才是证据。这样设计之后系统在回答“某个月电费到底是多少”“某笔钱是什么时候进来的”这类审计型问题时会变得非常高效。后续如果要想做数据对账、异常排查直接查流水就行不用去账单表里猜。2. 计费核心从抄表到账单的关键链路2.1 费率和计费规则怎么建模电费计费不是一个简单的“单价×电量”至少在我接触到的转供电场景里它会有两种很典型的规则一种是固定单价即电价不变直接用本期读数减去上期读数得到电量再乘以单价另一种是阶梯或峰谷电价不同时间段、不同用电区间对应不同单价。我在费率表里引入了tariff_type字段区分固定电价和阶梯电价同时加了effective_date和expire_date两个时间字段来控制费率版本。这样每次计算电费的时候服务会根据账单周期去捞对应生效的费率版本而不是写死在代码里。阶梯计费我实现了一个简单但足够用的方案把阶梯段位存成JSON数组比如0-300度是0.68元301-1000度是0.83元计费的时候逐段累计。虽然没法做到电网那种超精细化调节但对园区、商铺这类转供电场景完全够用。2.2 抄表数据流与异常读数处理电费征缴的基础是抄表数据如果读数错了后面所有的计算都是错的。这个系统在采集端支持两种方式一种是手工录入操作员在管理后台按表录入本期读数另一种是预留了对接采集设备的接口只要设备能推数据直接走MQTT或者HTTP回调写入meter_reading表。抄表最容易出问题的并不是“数据没传上来”而是异常读数。比如某块表这个月读数比上个月还小那就很可能是电表被换过、表计倒走或者录入错误。在我的设计里异常读数的数据一样会被保存但会打上reading_statusabnormal的标记并且不会参与自动计费。必须由操作员确认原因、手动修正之后才能把状态改为normal并触发重新计费。这一步在需求评审的时候差点被砍掉后来上线第二周就发挥了大作用——有块表因互感器故障导致读数跳变如果没有这个机制那个月账单就全错了。2.3 金额计算中的BigDecimal使用规范这是老生常谈但必须再强调一次的点金额一律用BigDecimal绝对不允许用double或float。电费计算涉及乘法、加法、四舍五入每一处都有可能产生浮点误差。我的做法是封装了一个MoneyUtils工具类里面统一了scale2和RoundingMode.HALF_UP所有金额计算都必须经过这个工具类。public class MoneyUtils { public static final int SCALE 2; public static BigDecimal multiply(BigDecimal price, BigDecimal quantity) { return price.multiply(quantity).setScale(SCALE, RoundingMode.HALF_UP); } public static BigDecimal add(BigDecimal... items) { BigDecimal sum BigDecimal.ZERO; for (BigDecimal item : items) { sum sum.add(item); } return sum.setScale(SCALE, RoundingMode.HALF_UP); } }表面上看这是一个工具类但其实它承担的是整个系统的“财务底线”。也可以在代码审查的时候跟团队约定死所有涉及金额的新代码必须走这个类如果谁直接new BigDecimal然后自己setScale代码审查直接打回。3. 征缴流程与状态机设计3.1 账单状态机从待缴到已销账账单是整个缴费流程的核心载体所以它的状态流转必须被严格约束。我把账单状态设计成四个UNPAID待缴费、PARTIAL_PAID部分缴费、PAID已缴清、CANCELLED已作废。业务上最常见的情况是租户扫码后一次性支付整张账单这时状态从UNPAID直接变到PAID。如果出现部分缴费、预存抵扣、或者手工减免状态流就会走到PARTIAL_PAID。这里有一个容易被忽略的点支付结果和账单状态不是同步的支付通道回调只是告诉你“这笔钱到了”真正让账单状态发生变化的是对账后或回调里组装好的销账逻辑。所以我在实现回调时并不会直接修改账单表状态而是先插入一条payment_record再去更新账单的paid_amount和status整个过程包裹在事务里。如果事务中途失败账单状态不变支付记录也不落库两边始终一致。3.2 第三方支付对接与幂等性保障微信支付Native下单的逻辑大致是后端通过商家订单号调用统一下单接口拿到code_url返回给前端前端生成二维码用户扫码支付后微信服务器会异步回调我们配置的notify_url把支付结果以XML或JSON形式POST到这个地址。我这边用的HTTP框架是Spring的RestTemplate签名验证用的是wechatpay-java官方SDK这一步不建议自己造轮子官方SDK对签名、证书轮换这些细节封装得比较完善能省掉很多潜在麻烦。但这里最大的坑是幂等。微信支付的回调机制是“多次通知、直到你确认成功”如果接口处理超时或者返回非2xx微信会间隔几秒、几分钟重复推送。如果不做幂等租户扫码付了100块回调被重复处理了三次那账单就会被销账三次资金流水直接爆掉。我在回调处理入口加了校验先根据out_trade_no查一下payment_record如果存在且状态已经是SUCCESS直接返回成功不再重复更新。public String handleNotify(PayNotifyRequest request) { String outTradeNo request.getOutTradeNo(); PaymentRecord existing paymentRecordMapper.selectByOutTradeNo(outTradeNo); if (existing ! null SUCCESS.equals(existing.getStatus())) { return SUCCESS; } // 校验签名 更新支付记录 更新账单状态 }3.3 对账任务与差错处理支付通道每天会产生对账单系统要做的是把这些账单和本地支付流水逐笔比对。如果渠道侧有一笔本地没有说明可能是回调丢失如果本地有一笔渠道侧没有可能是测试数据或渠道异常扣款。前一种情况我会拉取微信的账单文件解析后按out_trade_no去本地补齐支付记录同时更新账单状态。后一种情况会进入人工确认队列等待财务人员核对。写对账任务的时候要注意微信的对账单文件是CSV压缩包GBK编码直接用UTF-8解析会乱码。这个问题我第一次跑任务就踩到了排查了半天才发现是编码问题后来在解析逻辑里显式指定字符集解决。一般这类问题在真实联调时非常常见提前在代码里做兼容会省很多事。4. 前后端交互与核心接口实现4.1 接口设计风格与统一返回体这套系统采用RESTful风格统一返回结构为ResultT包含code、message和data三个字段。业务上自定义了一套错误码比如1001表示用户不存在1002表示费率未配置1003表示重复缴费。之所以不用HTTP状态码来表示业务错误是因为前端在拦截器里统一处理code比处理各种HTTP异常要方便得多尤其像参数校验失败、数据不存在这类情况HTTP 200 业务错误码反而是更常见的实践。4.2 账单查询与缴费下单核心流程账单查询接口是最常用的接口租户端需要看到当前待缴金额、历史账单和缴费状态。这个接口做了简单的缓存因为账单数据不是高频变化数据用Caffeine缓存10秒就能显著降低数据库压力。缴费下单接口则是先校验账单状态必须是UNPAID再调用微信支付服务创建预支付订单把code_url返回给前端。PostMapping(/api/payment/create) public ResultString createPayment(RequestBody PaymentCreateRequest request) { Bill bill billService.getById(request.getBillId()); if (bill null) { return Result.fail(1004, 账单不存在); } if (!UNPAID.equals(bill.getStatus()) !PARTIAL_PAID.equals(bill.getStatus())) { return Result.fail(1005, 当前账单状态不可缴费); } String codeUrl paymentService.createNativeOrder(bill); return Result.success(codeUrl); }4.3 管理后台的多租户数据隔离管理后台需要支持多个不同园区、不同项目的电费管理这就涉及数据隔离。最直接的方式是每个项目一个project_id所有的表都带上这个字段查询的时候通过MyBatis-Plus的拦截器自动拼上租户条件。我没有选择独立数据库的隔离方案因为单库多租户在维护成本和数据报表汇总上有很大优势只要在代码层做好强制过滤数据安全基本有保障。拦截器的实现方式也很简单自定义一个TenantLineInnerInterceptor在SQL解析阶段自动改写查询条件把project_id字段加进去。这样业务代码里完全不用关心租户条件只需要在登录态里解析出当前用户所属的项目ID即可。5. 核心难点与踩坑记录5.1 重复缴费仅靠“查找”防不住前面提到幂等性设计但在高并发场景下仅靠select update仍然有竞态问题。比如同一笔账单用户开着两个页面同时扫码两个请求同时查到账单状态是UNPAID然后同时创建了两个支付单这就可能出现两笔重复支付。为了解决这个问题我在数据库层面引入了唯一约束和分布式锁双保险payment_record表中的out_trade_no字段设置了唯一索引数据库层面禁止重复流水同时在下单前通过Redis的SETNX命令获取账单级锁保证同一时间只有一个下单请求在处理。5.2 定时任务漂移与分布式环境下重复执行电费征缴里有几个典型的定时任务每天凌晨生成前一日账单、每月1号生成月度账单、每15分钟扫描超时未支付的订单。单机部署时直接用Scheduled没有问题但一旦后面要搞多实例部署就会面临同一个任务被多个节点重复执行的问题。我的做法是用Scheduled配合ShedLock框架给任务加一个分布式锁确保同一个任务在同一时刻只有一个实例在跑。ShedLock的原理很简单在数据库里维护一张锁表任务执行前尝试插入锁记录插入成功的节点才执行任务执行完毕释放锁。这个方案对现有代码侵入很小只需要加注解和配置类。5.3 Actuator 开放端点的安全问题Spring Boot应用默认会暴露/actuator下的多个端点比如health、info、metrics、beans、heapdump等。这些端点在开发环境调试时确实方便但如果直接部署到生产环境且不加以保护问题会很大——heapdump端点可能泄露内存中的敏感信息shutdown端点如果被误开可以直接让服务宕机。我的处理原则是生产环境只暴露health和metrics而且给Actuator单独加了一套访问认证其他人访问必须携带管理员Token才有权限。折中一点的做法是使用Spring Security配合路径权限配置将/actuator/**的访问全部拦下来只允许内网IP或特定服务账号访问。5.4 数据库连接池与批量写入配置优化电费系统里频率最高的写操作就是抄表数据的批量导入。一次导入可能涉及几千条甚至上万条读数如果用MyBatis-Plus默认的单条insert性能会非常差。后来我改成了SqlSessionTemplate批量提交每一批500条配合MySQL的rewriteBatchedStatementstrue参数写入效率提升了接近10倍。这里还有个隐藏的性能点数据库连接池的max-active不要太低默认的HikariCP配置是10在批量导入导出或报表生成时很容易出现连接等待超时。我调整到了50同时设置了max-lifetime为30分钟避免长时间占用连接导致MySQL主动断开。6. 数据库设计要点与查询优化6.1 核心表结构概览这里列一下最核心的几张表。表名核心字段作用说明customerid, project_id, name, phone, address租户/业主基础档案meterid, project_id, customer_id, meter_no, install_date电表档案关联用户meter_readingid, meter_id, reading_value, reading_date, status抄表读数支持异常标记tariffid, project_id, tariff_type, price, start_date, end_date费率表区分固定/阶梯billid, customer_id, period, total_amount, status, paid_amount账单主表按月生成payment_recordid, bill_id, out_trade_no, amount, status, transaction_id支付流水对接渠道6.2 抄表数据的索引设计抄表数据是典型的时序数据查询场景通常是“查某块表某个时间段内的所有读数”。所以索引设计上采用复合索引(meter_id, reading_date)既满足电表维度的过滤也能高效支持时间范围查询。账单表的索引稍微复杂一点因为查询维度有客户、有状态、有账期我建了(customer_id, period, status)的联合索引大部分列表查询都能命中索引避免全表扫描。6.3 慢查询分析与分页优化系统上线一段时间后账单查询接口偶尔出现慢查询用慢查询日志定位后发现是bill表在period字段上的条件让索引失效。原因很直白period字段存的是格式为2025-06的字符串查询时如果参数是Date类型数据库隐式转换导致索引失效。整改方式是统一用字符串传参并且把接口层入参也改成字符串避免任何隐式转换的机会。分页方面MyBatis-Plus默认的分页插件对大数据量深分页不太友好比如查第10000页时会把前10000页的数据都查出来再剔除。对于报表类查询我改成了基于游标的方案也就是记住上一页最后一条记录的ID用WHERE id ?来获取下一页这样无论翻到多深查询耗时可稳定在几十毫秒以内。7. 部署、权限与其他落地细节7.1 项目目录规范与团队协作Spring Boot项目的目录结构我按常见的领域分包方式组织而不是严格按controller/service/mapper三层横向分包。因为电费征缴系统的业务边界非常清晰按领域分包能把高内聚的代码放在一起避免service层越写越臃肿。com.example.ems ├── common // 统一返回体、异常、工具类 ├── customer // 用户/租户管理 ├── meter // 电表与抄表 ├── billing // 账单与计费 ├── payment // 缴费与支付渠道对接 └── report // 报表与统计7.2 接口访问控制与操作日志系统的管理端接口都要求登录token并且基于接口路径做了权限码控制。比如/api/bill/export要求billing:export权限/api/payment/refund要求payment:refund权限。权限数据不引入重型的权限框架直接基于Spring Security的注解式PreAuthorize实现简单够用。操作日志是一个平时不起眼、但审计时非常重要的模块。所有涉及金额调整、账单作废、费率修改的操作都必须记录操作人、操作时间、操作前后快照和操作原因。这块我用了Aspect注解切面的方式在需要记录日志的方法上标注自定义注解统一异步写入日志表不影响主流程性能。7.3 Maven多环境配置与打包实践项目按dev、test、prod三套环境做了profile配置每个环境维护独立的application-{profile}.yml。数据库连接、Redis地址、支付回调域名、日志级别都通过占位符从环境变量注入避免敏感信息直接提交到代码仓库。打包时使用mvn clean package -DskipTests -Pprod利用Spring Boot Maven插件打成可执行jar再配合部署脚本做蓝绿发布基本能做到平滑上线不中断。8. 写在最后的几点体会这套系统从零到一落地之后我最大的感受是电费征缴这类“传统”业务系统技术难度并不在于用了多新的框架而在于你怎么把现实的计费规则、支付流程、审计要求用工程化的方式稳定地表达出来。如果现在让我重新再写一遍我会在一开始就给账单和流水增加更完善的对账标记字段因为后续接财务系统时发现很多对账信息在前期并没有被完整记录导致需要额外补数据脚本迁移。另外尽量早地引入操作日志体系也非常值得不要在系统上线之后再补那时候补起来会非常痛苦。如果你也正在做类似系统建议把重点放在状态机的严谨性和金额计算的规范性上这两个点稳住了系统基本不会出大问题。后面如果要扩展预付费模式、对接更多支付渠道或者接入采集设备做自动抄表整个框架都可以平滑支撑不会伤筋动骨。本文还有配套的精品资源点击获取 Spring Boot 3.2电费征缴系统EMS设计与实践
简介基于Spring Boot的电费征缴系统EMS是一份面向Java学习者与电力行业信息化开发者的完整项目源码重点演示企业级Web系统从用户管理、电费计算到在线缴费、报表统计的落地实现。压缩包内共23个文件包含16个Java源文件、Maven构建配置、项目说明文档及运行辅助脚本整体大小仅19KB适合快速读懂核心代码结构。已有273人学习访问资源以Maven标准工程组织通过Spring Data JPA、Spring Security等典型组件展示后端服务、安全控制与支付集成的常用写法读者可据此梳理业务模块划分并参考README完成本地环境搭建与二次开发。 EMS在快递行业是那个邮政特快专递但在用电管理圈子里它指的是Electricity Management System——电费征缴管理系统。我这个项目就是一套跑在Spring Boot 3.2之上的电费征缴系统核心解决的是那种“物业/园区/转供电主体手里一堆电表却还在用Excel算费、微信催缴、手工登记”的老大难问题。如果你正在给学校、产业园区、商业综合体或者工厂做能耗计费和收费管理这篇实践记录会很有参考价值。这类系统表面上就是一个计费加收钱的小工具但真正拆开做之后你会发现坑全藏在“电费规则怎么配置”“账单状态怎么流转”“金额怎么保证一分不差”这些细节里。这套系统我从数据库建模到接口联调、再到后续和支付通道对接前后花了差不多三周踩了不少坑也沉淀了一些通用做法下面把整个项目的核心设计和关键代码完整记录一遍。1. 项目初衷与整体设计思路1.1 为什么叫“EMS”而不是普通的“缴费系统”很多人在第一次听到“EMS”的时候首先想到的是邮政快递但在能源管理这个具体场景里EMS的含义更偏向“管理”而非单纯“收费”。传统的电费管理流程是人工抄表、手工算费、线下催缴数据散落在纸面和Excel里到了对账的时候非常痛苦。我做的这套EMS系统从一开始就把“管理”放在了“收费”前面也就是先管住设备、管住读数、管住费率最后才是收钱。也因此系统被拆成了几个大的业务域基础档案域管用户和电表计量域管抄表数据和异常读数计费域管费率计算和账单生成结算域管缴费和对账。每个域之间通过数据库表结构和领域服务解耦互相不越界这对于后续要扩展预付费、阶梯电价、分时电价这些能力会非常关键。1.2 技术栈选型Spring Boot 3.x MyBatis-Plus MySQL技术选型没有太多花哨的东西就是当前Java后端最主流的一套组合。Spring Boot选了3.2.x版本JDK 17因为Spring Boot 3.x是基于Jakarta EE命名空间相比2.x性能更好、生态也在快速迁移。MyBatis-Plus做持久层不是为了复杂的SQL生成而是看中它的分页插件和LambdaQueryWrapper能让业务代码干净不少。数据库用的MySQL 8.0存储引擎InnoDB字符集utf8mb4排序规则utf8mb4_general_ci——这里有个小细节值得留意电费系统里会出现业主名称这类中文数据如果排序规则没选对后续like查询可能遇到乱码或索引失效的问题。支付模块对接的是通用的微信支付Native下单之所以没有做支付宝是因为实际项目里物业方和园区方的诉求高度一致租户或业主扫码就能付后台能看到每一笔回调结果。用Native支付的好处是后端不感知前端扫码环境只需要返回一个二维码链接前端自绘二维码即可联调成本很低。1.3 架构上的“三独立”原则这套EMS在设计上我给自己定了一个“三独立”原则费率独立、账单独立、流水独立。费率独立指的是费率表不直接绑定到账单上而是通过版本号和时间段去关联这样电价调整的时候历史账单不受影响。账单独立是指一条账单记录只属于一个计费周期不允许跨周期合并哪怕某个租户两个月都没交费也必须生成两张账单方便后续滞纳金计算和财务核销。流水独立则是指每一笔支付回调、每一笔退款、每一笔手工调整都必须落到流水表里账单金额只是结果流水才是证据。这样设计之后系统在回答“某个月电费到底是多少”“某笔钱是什么时候进来的”这类审计型问题时会变得非常高效。后续如果要想做数据对账、异常排查直接查流水就行不用去账单表里猜。2. 计费核心从抄表到账单的关键链路2.1 费率和计费规则怎么建模电费计费不是一个简单的“单价×电量”至少在我接触到的转供电场景里它会有两种很典型的规则一种是固定单价即电价不变直接用本期读数减去上期读数得到电量再乘以单价另一种是阶梯或峰谷电价不同时间段、不同用电区间对应不同单价。我在费率表里引入了tariff_type字段区分固定电价和阶梯电价同时加了effective_date和expire_date两个时间字段来控制费率版本。这样每次计算电费的时候服务会根据账单周期去捞对应生效的费率版本而不是写死在代码里。阶梯计费我实现了一个简单但足够用的方案把阶梯段位存成JSON数组比如0-300度是0.68元301-1000度是0.83元计费的时候逐段累计。虽然没法做到电网那种超精细化调节但对园区、商铺这类转供电场景完全够用。2.2 抄表数据流与异常读数处理电费征缴的基础是抄表数据如果读数错了后面所有的计算都是错的。这个系统在采集端支持两种方式一种是手工录入操作员在管理后台按表录入本期读数另一种是预留了对接采集设备的接口只要设备能推数据直接走MQTT或者HTTP回调写入meter_reading表。抄表最容易出问题的并不是“数据没传上来”而是异常读数。比如某块表这个月读数比上个月还小那就很可能是电表被换过、表计倒走或者录入错误。在我的设计里异常读数的数据一样会被保存但会打上reading_statusabnormal的标记并且不会参与自动计费。必须由操作员确认原因、手动修正之后才能把状态改为normal并触发重新计费。这一步在需求评审的时候差点被砍掉后来上线第二周就发挥了大作用——有块表因互感器故障导致读数跳变如果没有这个机制那个月账单就全错了。2.3 金额计算中的BigDecimal使用规范这是老生常谈但必须再强调一次的点金额一律用BigDecimal绝对不允许用double或float。电费计算涉及乘法、加法、四舍五入每一处都有可能产生浮点误差。我的做法是封装了一个MoneyUtils工具类里面统一了scale2和RoundingMode.HALF_UP所有金额计算都必须经过这个工具类。public class MoneyUtils { public static final int SCALE 2; public static BigDecimal multiply(BigDecimal price, BigDecimal quantity) { return price.multiply(quantity).setScale(SCALE, RoundingMode.HALF_UP); } public static BigDecimal add(BigDecimal... items) { BigDecimal sum BigDecimal.ZERO; for (BigDecimal item : items) { sum sum.add(item); } return sum.setScale(SCALE, RoundingMode.HALF_UP); } }表面上看这是一个工具类但其实它承担的是整个系统的“财务底线”。也可以在代码审查的时候跟团队约定死所有涉及金额的新代码必须走这个类如果谁直接new BigDecimal然后自己setScale代码审查直接打回。3. 征缴流程与状态机设计3.1 账单状态机从待缴到已销账账单是整个缴费流程的核心载体所以它的状态流转必须被严格约束。我把账单状态设计成四个UNPAID待缴费、PARTIAL_PAID部分缴费、PAID已缴清、CANCELLED已作废。业务上最常见的情况是租户扫码后一次性支付整张账单这时状态从UNPAID直接变到PAID。如果出现部分缴费、预存抵扣、或者手工减免状态流就会走到PARTIAL_PAID。这里有一个容易被忽略的点支付结果和账单状态不是同步的支付通道回调只是告诉你“这笔钱到了”真正让账单状态发生变化的是对账后或回调里组装好的销账逻辑。所以我在实现回调时并不会直接修改账单表状态而是先插入一条payment_record再去更新账单的paid_amount和status整个过程包裹在事务里。如果事务中途失败账单状态不变支付记录也不落库两边始终一致。3.2 第三方支付对接与幂等性保障微信支付Native下单的逻辑大致是后端通过商家订单号调用统一下单接口拿到code_url返回给前端前端生成二维码用户扫码支付后微信服务器会异步回调我们配置的notify_url把支付结果以XML或JSON形式POST到这个地址。我这边用的HTTP框架是Spring的RestTemplate签名验证用的是wechatpay-java官方SDK这一步不建议自己造轮子官方SDK对签名、证书轮换这些细节封装得比较完善能省掉很多潜在麻烦。但这里最大的坑是幂等。微信支付的回调机制是“多次通知、直到你确认成功”如果接口处理超时或者返回非2xx微信会间隔几秒、几分钟重复推送。如果不做幂等租户扫码付了100块回调被重复处理了三次那账单就会被销账三次资金流水直接爆掉。我在回调处理入口加了校验先根据out_trade_no查一下payment_record如果存在且状态已经是SUCCESS直接返回成功不再重复更新。public String handleNotify(PayNotifyRequest request) { String outTradeNo request.getOutTradeNo(); PaymentRecord existing paymentRecordMapper.selectByOutTradeNo(outTradeNo); if (existing ! null SUCCESS.equals(existing.getStatus())) { return SUCCESS; } // 校验签名 更新支付记录 更新账单状态 }3.3 对账任务与差错处理支付通道每天会产生对账单系统要做的是把这些账单和本地支付流水逐笔比对。如果渠道侧有一笔本地没有说明可能是回调丢失如果本地有一笔渠道侧没有可能是测试数据或渠道异常扣款。前一种情况我会拉取微信的账单文件解析后按out_trade_no去本地补齐支付记录同时更新账单状态。后一种情况会进入人工确认队列等待财务人员核对。写对账任务的时候要注意微信的对账单文件是CSV压缩包GBK编码直接用UTF-8解析会乱码。这个问题我第一次跑任务就踩到了排查了半天才发现是编码问题后来在解析逻辑里显式指定字符集解决。一般这类问题在真实联调时非常常见提前在代码里做兼容会省很多事。4. 前后端交互与核心接口实现4.1 接口设计风格与统一返回体这套系统采用RESTful风格统一返回结构为ResultT包含code、message和data三个字段。业务上自定义了一套错误码比如1001表示用户不存在1002表示费率未配置1003表示重复缴费。之所以不用HTTP状态码来表示业务错误是因为前端在拦截器里统一处理code比处理各种HTTP异常要方便得多尤其像参数校验失败、数据不存在这类情况HTTP 200 业务错误码反而是更常见的实践。4.2 账单查询与缴费下单核心流程账单查询接口是最常用的接口租户端需要看到当前待缴金额、历史账单和缴费状态。这个接口做了简单的缓存因为账单数据不是高频变化数据用Caffeine缓存10秒就能显著降低数据库压力。缴费下单接口则是先校验账单状态必须是UNPAID再调用微信支付服务创建预支付订单把code_url返回给前端。PostMapping(/api/payment/create) public ResultString createPayment(RequestBody PaymentCreateRequest request) { Bill bill billService.getById(request.getBillId()); if (bill null) { return Result.fail(1004, 账单不存在); } if (!UNPAID.equals(bill.getStatus()) !PARTIAL_PAID.equals(bill.getStatus())) { return Result.fail(1005, 当前账单状态不可缴费); } String codeUrl paymentService.createNativeOrder(bill); return Result.success(codeUrl); }4.3 管理后台的多租户数据隔离管理后台需要支持多个不同园区、不同项目的电费管理这就涉及数据隔离。最直接的方式是每个项目一个project_id所有的表都带上这个字段查询的时候通过MyBatis-Plus的拦截器自动拼上租户条件。我没有选择独立数据库的隔离方案因为单库多租户在维护成本和数据报表汇总上有很大优势只要在代码层做好强制过滤数据安全基本有保障。拦截器的实现方式也很简单自定义一个TenantLineInnerInterceptor在SQL解析阶段自动改写查询条件把project_id字段加进去。这样业务代码里完全不用关心租户条件只需要在登录态里解析出当前用户所属的项目ID即可。5. 核心难点与踩坑记录5.1 重复缴费仅靠“查找”防不住前面提到幂等性设计但在高并发场景下仅靠select update仍然有竞态问题。比如同一笔账单用户开着两个页面同时扫码两个请求同时查到账单状态是UNPAID然后同时创建了两个支付单这就可能出现两笔重复支付。为了解决这个问题我在数据库层面引入了唯一约束和分布式锁双保险payment_record表中的out_trade_no字段设置了唯一索引数据库层面禁止重复流水同时在下单前通过Redis的SETNX命令获取账单级锁保证同一时间只有一个下单请求在处理。5.2 定时任务漂移与分布式环境下重复执行电费征缴里有几个典型的定时任务每天凌晨生成前一日账单、每月1号生成月度账单、每15分钟扫描超时未支付的订单。单机部署时直接用Scheduled没有问题但一旦后面要搞多实例部署就会面临同一个任务被多个节点重复执行的问题。我的做法是用Scheduled配合ShedLock框架给任务加一个分布式锁确保同一个任务在同一时刻只有一个实例在跑。ShedLock的原理很简单在数据库里维护一张锁表任务执行前尝试插入锁记录插入成功的节点才执行任务执行完毕释放锁。这个方案对现有代码侵入很小只需要加注解和配置类。5.3 Actuator 开放端点的安全问题Spring Boot应用默认会暴露/actuator下的多个端点比如health、info、metrics、beans、heapdump等。这些端点在开发环境调试时确实方便但如果直接部署到生产环境且不加以保护问题会很大——heapdump端点可能泄露内存中的敏感信息shutdown端点如果被误开可以直接让服务宕机。我的处理原则是生产环境只暴露health和metrics而且给Actuator单独加了一套访问认证其他人访问必须携带管理员Token才有权限。折中一点的做法是使用Spring Security配合路径权限配置将/actuator/**的访问全部拦下来只允许内网IP或特定服务账号访问。5.4 数据库连接池与批量写入配置优化电费系统里频率最高的写操作就是抄表数据的批量导入。一次导入可能涉及几千条甚至上万条读数如果用MyBatis-Plus默认的单条insert性能会非常差。后来我改成了SqlSessionTemplate批量提交每一批500条配合MySQL的rewriteBatchedStatementstrue参数写入效率提升了接近10倍。这里还有个隐藏的性能点数据库连接池的max-active不要太低默认的HikariCP配置是10在批量导入导出或报表生成时很容易出现连接等待超时。我调整到了50同时设置了max-lifetime为30分钟避免长时间占用连接导致MySQL主动断开。6. 数据库设计要点与查询优化6.1 核心表结构概览这里列一下最核心的几张表。表名核心字段作用说明customerid, project_id, name, phone, address租户/业主基础档案meterid, project_id, customer_id, meter_no, install_date电表档案关联用户meter_readingid, meter_id, reading_value, reading_date, status抄表读数支持异常标记tariffid, project_id, tariff_type, price, start_date, end_date费率表区分固定/阶梯billid, customer_id, period, total_amount, status, paid_amount账单主表按月生成payment_recordid, bill_id, out_trade_no, amount, status, transaction_id支付流水对接渠道6.2 抄表数据的索引设计抄表数据是典型的时序数据查询场景通常是“查某块表某个时间段内的所有读数”。所以索引设计上采用复合索引(meter_id, reading_date)既满足电表维度的过滤也能高效支持时间范围查询。账单表的索引稍微复杂一点因为查询维度有客户、有状态、有账期我建了(customer_id, period, status)的联合索引大部分列表查询都能命中索引避免全表扫描。6.3 慢查询分析与分页优化系统上线一段时间后账单查询接口偶尔出现慢查询用慢查询日志定位后发现是bill表在period字段上的条件让索引失效。原因很直白period字段存的是格式为2025-06的字符串查询时如果参数是Date类型数据库隐式转换导致索引失效。整改方式是统一用字符串传参并且把接口层入参也改成字符串避免任何隐式转换的机会。分页方面MyBatis-Plus默认的分页插件对大数据量深分页不太友好比如查第10000页时会把前10000页的数据都查出来再剔除。对于报表类查询我改成了基于游标的方案也就是记住上一页最后一条记录的ID用WHERE id ?来获取下一页这样无论翻到多深查询耗时可稳定在几十毫秒以内。7. 部署、权限与其他落地细节7.1 项目目录规范与团队协作Spring Boot项目的目录结构我按常见的领域分包方式组织而不是严格按controller/service/mapper三层横向分包。因为电费征缴系统的业务边界非常清晰按领域分包能把高内聚的代码放在一起避免service层越写越臃肿。com.example.ems ├── common // 统一返回体、异常、工具类 ├── customer // 用户/租户管理 ├── meter // 电表与抄表 ├── billing // 账单与计费 ├── payment // 缴费与支付渠道对接 └── report // 报表与统计7.2 接口访问控制与操作日志系统的管理端接口都要求登录token并且基于接口路径做了权限码控制。比如/api/bill/export要求billing:export权限/api/payment/refund要求payment:refund权限。权限数据不引入重型的权限框架直接基于Spring Security的注解式PreAuthorize实现简单够用。操作日志是一个平时不起眼、但审计时非常重要的模块。所有涉及金额调整、账单作废、费率修改的操作都必须记录操作人、操作时间、操作前后快照和操作原因。这块我用了Aspect注解切面的方式在需要记录日志的方法上标注自定义注解统一异步写入日志表不影响主流程性能。7.3 Maven多环境配置与打包实践项目按dev、test、prod三套环境做了profile配置每个环境维护独立的application-{profile}.yml。数据库连接、Redis地址、支付回调域名、日志级别都通过占位符从环境变量注入避免敏感信息直接提交到代码仓库。打包时使用mvn clean package -DskipTests -Pprod利用Spring Boot Maven插件打成可执行jar再配合部署脚本做蓝绿发布基本能做到平滑上线不中断。8. 写在最后的几点体会这套系统从零到一落地之后我最大的感受是电费征缴这类“传统”业务系统技术难度并不在于用了多新的框架而在于你怎么把现实的计费规则、支付流程、审计要求用工程化的方式稳定地表达出来。如果现在让我重新再写一遍我会在一开始就给账单和流水增加更完善的对账标记字段因为后续接财务系统时发现很多对账信息在前期并没有被完整记录导致需要额外补数据脚本迁移。另外尽量早地引入操作日志体系也非常值得不要在系统上线之后再补那时候补起来会非常痛苦。如果你也正在做类似系统建议把重点放在状态机的严谨性和金额计算的规范性上这两个点稳住了系统基本不会出大问题。后面如果要扩展预付费模式、对接更多支付渠道或者接入采集设备做自动抄表整个框架都可以平滑支撑不会伤筋动骨。本文还有配套的精品资源点击获取