简介面向计算机类毕业设计或课程作业的智慧能耗管理系统后端项目适合需要完成同类课题或学习企业级后端架构的开发者。资源以Java技术栈为主277个Java源码文件承载核心业务逻辑171个XML文件用于配置与对象映射另有10个JAR依赖、7个properties环境配置及构建部署相关文件覆盖接口定义、服务实现、数据持久化和系统部署等完整环节。压缩包共481个文件大小约53.56MB根目录按common、dao、interface、report、web等模块划分便于按功能定位代码与资源。目前已有67人学习下载。通过研读源码可深入理解能耗数据采集、智能分析与预测、节能策略调度的后端实现思路项目中的文档、测试用例与部署脚本还能帮助学习者熟悉项目结构、验证流程与上线方式提升从需求分析到系统落地的综合工程能力。1. 智慧能耗管理系统后端在解决什么从看懂包到跑通整条链路一个毕设或课程作业的智慧能耗管理系统后端打包出来往往看着像黑匣子一坨配置、几十个 Java 文件、入口都不知道在哪。我拆过不少这类项目真正值钱的不是界面效果而是能耗数据从采集、存储到统计、告警这条链路有没有跑通。所谓擎联科技智慧能耗管理系统后端本质就是一个接收电表、水表等计量设备上报数据按时间维度聚合统计再向前端输出报表与告警的服务端程序。它适合两类人一类是拿这个题目做毕设、想快速把后端跑起来再改造成自己东西的同学另一类是刚转 Java 后端、想找个完整项目练手的开发者。这套系统的核心只有三件事把数据存下来、把数据算出来、把异常报出来。2. 能耗数据采集与入库从设备报文到 MySQL 的落地路径2.1 表结构设计为什么我建议用测点模型而不是设备模型能耗管理系统的第一步是决定数据怎么躺进数据库。常见的错误做法是“一个设备一行”直接把设备的功率、电压、电流、电量全建成字段。这种设备模型看着直观但加一个测点就要加一列统计某个具体指标时还得从一行里抠好几个字段后面写聚合 SQL 会非常别扭。我一般用测点模型设备档案单独一张表数据表只存“哪个设备、哪个测点、什么时间、什么值”一行只描述一个信号。以电表为例一个电表可能上报当前功率、电量、电压、电流四个测点那就是四条记录。这样设计的好处是统计口径统一后续加气表、水表不需要改表结构。毕设级别完全没必要上时序数据库MySQL 在加了索引后扛住百万级能耗数据没有问题而且部署环境要求低答辩演示不折腾。CREATE TABLE device_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 设备ID, device_code VARCHAR(64) NOT NULL COMMENT 设备编号对应现场表计编号, device_name VARCHAR(128) NOT NULL COMMENT 设备名称, device_type TINYINT NOT NULL COMMENT 1-电表 2-水表 3-气表, location VARCHAR(255) COMMENT 安装位置如A栋3层会议室, rate DECIMAL(10,4) DEFAULT 1.0000 COMMENT 互感器倍率电表读数需乘该值得到实际能耗, enabled TINYINT DEFAULT 1 COMMENT 1-启用 0-停用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_type_location (device_type, location) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT计量设备档案;这张表里最容易被忽略的是rate字段。现场电表如果接了互感器表上读到的数值要乘以倍率才是真实能耗很多毕设项目没这个字段导致报表数据跟物业电费单对不上。device_code要保持唯一因为采集器上报时只认编号不认自增主键。CREATE TABLE energy_data ( id BIGINT PRIMARY KEY AUTO_INCREMENT, device_id BIGINT NOT NULL COMMENT 关联device_info.id, point_code VARCHAR(32) NOT NULL COMMENT 测点编码如P/ACT_ENERGY表示有功电量, data_value DECIMAL(18,4) NOT NULL COMMENT 测点数值, data_time DATETIME NOT NULL COMMENT 数据发生时间来自设备/网关时间, raw_json JSON DEFAULT NULL COMMENT 原始报文排错时用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 落库时间, KEY idx_device_time (device_id, data_time), KEY idx_point_time (point_code, data_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT测点时序数据;这两个索引分别覆盖两种最常见的查询按设备查一段时间内的所有数据、按测点类型查某类信号的趋势。data_time和create_time分开存是有讲究的网关断网补报时数据发生时间和入库时间可能差几个小时如果统计时误用了create_time报表上的曲线会出现诡异的“归位”现象电量数据直接算错。2.2 上报接口与批量入库Controller 怎么写、批量参数怎么调采集器上报通常是一批数据一起 POST 过来所以接口入参设计成 List。常见做法是网关每隔几分钟推一次每次几十到几百条。接收端要做的第一件事是验空第二件事就是把 DTO 转成实体然后一次性批量插入。RestController RequestMapping(/api/v1/collect) public class DataCollectController { PostMapping(/report) public ResultBoolean report(RequestBody ListMeterDataDTO list) { if (list null || list.isEmpty()) { return Result.fail(上报数据为空); } // 设备号和测点编码的合法性交给定时任务校验上报链路只做格式转换 ListEnergyData entities list.stream().map(d - { EnergyData e new EnergyData(); e.setDeviceId(d.getDeviceId()); e.setPointCode(d.getPointCode()); e.setDataValue(d.getDataValue()); e.setDataTime(d.getDataTime()); e.setRawJson(JSON.toJSONString(d)); return e; }).collect(Collectors.toList()); energyDataMapper.batchInsert(entities); return Result.success(Boolean.TRUE); } }为什么不在上报时校验 device_id 是否存在因为高频上报场景下每一条都先 SELECT 再 INSERT 会让吞吐量掉一半而且采集器偶发重推时这种校验形同虚设。更稳的做法是入库后用定时任务扫出无效的 device_id在统计聚合时过滤掉。这是采集链路上一个值得记住的取舍链路越短抗压能力越强。Mapper 里的批量插入用 foreach 拼接这是 MyBatis 最常见的写法insert idbatchInsert parameterTypelist insert into energy_data (device_id, point_code, data_value, data_time, raw_json, create_time) values foreach collectionlist itemitem separator, (#{item.deviceId}, #{item.pointCode}, #{item.dataValue}, #{item.dataTime}, #{item.rawJson}, now()) /foreach /insert这里有两个参数直接影响成败。第一个是 JDBC 连接串要加rewriteBatchedStatementstrue否则批量插入会被驱动拆成单条执行性能优势消失第二个是单批条数要控制在 500 到 1000 之间超过之后容易撞上 MySQL 的max_allowed_packet限制接口会偶发性报PacketTooBigException。批次大小最好在代码里按固定阈值切分而不是依赖前端传多少就塞多少。3. 核心业务服务统计聚合与告警判定的实现3.1 按日/月/年聚合SQL 写法与数据口径的统一能耗管理系统最常被打开的两个页面就是能耗看板和能耗报表而这两个页面本质上都在做同一件事按时间粒度把明细数据汇总。新手最爱犯的错是在 Java 里把明细查出来再用 for 循环逐条累加。这种做法在小数据量时看不出问题一旦数据表上了十万行接口响应就会从秒级掉到分钟级而且每次统计的逻辑分散在各处口径很难统一。正确的做法是把聚合下推到 MySQL让数据库只返回汇总后的结果SELECT DATE_FORMAT(data_time, %Y-%m-%d) AS stat_date, SUM(CASE WHEN point_code P/ACT_ENERGY THEN data_value ELSE 0 END) AS energy_sum FROM energy_data WHERE device_id #{deviceId} AND point_code P/ACT_ENERGY AND data_time #{startTime} AND data_time #{endTime} GROUP BY stat_date ORDER BY stat_date;这个 SQL 有几个细节值得说。DATE_FORMAT(data_time, %Y-%m-%d)在 GROUP BY 里使用后虽然无法直接走索引但外层 WHERE 已经用data_time范围把数据限定住了所以性能依然可接受。如果数据量真的到了需要优化的时候再改成按时间分区表查询时让优化器自动裁剪分区即可。point_code的命名要保持语义一致比如有功电量统一叫P/ACT_ENERGY这样CASE WHEN才能准确把对应测点捞出来。统计口径一旦定下来所有接口都走这一个 Mapper避免前端展示一个数、导出报表又是另一个数。3.2 告警规则设计阈值告警、趋势告警与离线告警告警是智慧能耗系统里区别于普通报表系统的关键功能。常见的告警类型有三种固定阈值告警比如功率超过 80kW 就报警趋势告警比如最近 5 分钟的平均功率比上一个 5 分钟高出 20%说明设备可能异常运行还有一种是离线告警某个设备超过 15 分钟没有上报数据可能是通信断了。告警规则本身也是一张表用规则配置驱动而不是硬编码在 Java 里CREATE TABLE alarm_rule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, rule_name VARCHAR(50) NOT NULL COMMENT 规则名称, device_type TINYINT NOT NULL COMMENT 作用于哪类设备, point_code VARCHAR(32) NOT NULL COMMENT 监测的测点, rule_type TINYINT NOT NULL COMMENT 1-阈值 2-环比突增 3-离线, threshold DECIMAL(12,4) COMMENT 阈值或环比百分比, compare_op VARCHAR(2) DEFAULT GT COMMENT GT/LT, window_minutes INT NOT NULL COMMENT 统计窗口趋势告警表示对比周期, enabled TINYINT DEFAULT 1 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT告警规则表;规则类型对应一个告警判定服务用定时任务每隔一分钟跑一次。为什么不在数据上报时同步判断因为上报接口在数据洪峰时 CPU 已经吃紧再叠加规则判断会让采集链路变慢而且规则调整时还得重启服务。放到定时任务里规则的修改即时生效判定逻辑也集中在一处。Component public class AlarmJudge { Scheduled(fixedDelay 60000, initialDelay 10000) public void judge() { // 每次只取最近5分钟的数据按设备、测点聚合成最近周期的均值 ListEnergyData recent energyDataMapper.selectRecent(5); for (AlarmRule rule : alarmRuleMapper.selectEnabled()) { switch (rule.getRuleType()) { case 1 - judgeThreshold(rule, recent); case 2 - judgeTrend(rule, recent); case 3 - judgeOffline(rule); } } } }这段代码里最关键的参数是fixedDelay 60000表示上一次任务执行完毕后再等 60 秒才跑下一轮比fixedRate更安全不会出现任务堆积。window_minutes决定趋势告警的对比粒度一般是 5 到 15 分钟太短容易被瞬时波动误报太长又会让异常设备带病运行太久。判定出告警后插入告警记录表同时注意给告警记录加上“未恢复”状态位否则每个周期都会重复插入几分钟之内就能刷出几十条这就是俗称的“告警风暴”。4. 前后端分离联调接口契约、鉴权与跨域配置4.1 REST 接口与统一返回体让前端拿到能直接用的数据这套系统如果按前后端分离来做Controller 层最先要定下来的不是接口数量而是返回格式。Vue 或 React 项目里的 axios 拦截器通常期望一个统一结构比如{ code, message, data }。我见过不少毕设后端登录接口返回 token 字符串、报表接口返回数组、异常时直接抛 500 页面前端每个接口都得写一套特判联调时苦不堪言。统一返回体的做法并不复杂public class ResultT { private int code; private String msg; private T data; public static T ResultT success(T data) { ResultT r new Result(); r.code 200; r.msg ok; r.data data; return r; } public static T ResultT fail(String msg) { ResultT r new Result(); r.code 500; r.msg msg; r.data null; return r; } }code表示业务状态码HTTP 状态码只负责传输层面是否正常。业务上参数校验失败、token 过期、数据不存在都应该由code区分而不是让 HTTP 层面直接 500。分页接口再包一层PageResult里面固定带list、total、pageNum、pageSize四个字段前端无论用 el-table 还是 antd 的表格组件都能直接映射。分页这里有一个高频坑MyBatis 的 PageHelper 默认页码是 1 开始的但部分前端分页组件用的页码从 0 开始。如果前后端没对齐第一页数据永远是空的。联调前先把接口文档字段定义清楚Controller 入参上显式标注RequestParam(pageNum)不要依赖框架的自动映射去猜字段名。4.2 后端跨域配置与鉴权前后端分离最容易断的两根线前端跑在 8080 端口后端跑在 8081 端口一联调就出 CORS 错这是前后端分离项目最常见的第一道坎。对于没有引入 Spring Security 的项目一个 WebMvcConfigurer 配置类就能解决Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(http://localhost:*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }这里有两个必须注意的参数。allowedOriginPatterns别写成*因为一旦allowCredentials(true)被打开浏览器就不允许用通配符作为允许来源明确写上本地前端的地址模式更安全。maxAge(3600)表示预检请求的结果在浏览器缓存 1 小时减少了每次请求都要先发 OPTIONS 的开销。如果项目是基于若依RuoYi这类脚手架改的光配这个还不够。Spring Security 的过滤器链会先于 CORS 拦截器执行OPTIONS 预检请求如果没有被放行前端依然会报跨域错误。这时候需要在 SecurityConfig 里显式放行request.getMethod().equals(OPTIONS)。这套前后端分离项目里典型的翻车组合排查时先看浏览器请求面板如果预检请求返回 401 再考虑 Security 配置如果返回 405 就是 CORS 配置本身的问题。鉴权方面毕设项目不需要引入 OAuth2 那套重量级方案JWT 足够。登录接口发放 token拦截器校验合法性把用户信息放到 ThreadLocal 里供后续接口使用。需要注意 token 过期时间不要设成“永不过期”答辩演示时如果被问到安全性这算一个加分点但也可以用一个两小时的有效期配合前端路由守卫来刷新。5. 智慧能耗后端搭建避坑4 个最常见的翻车现场5.1 统计查询越查越慢时间字段没有索引现象系统上线两周后能耗报表页打开要十几秒数据量只有几十万行。原因energy_data表只给device_id建了索引data_time没有参与任何索引统计 SQL 的 WHERE 条件里虽然带data_time范围过滤但优化器只能拿device_id定位后做逐行扫描。用EXPLAIN看执行计划type显示ALL就是全表扫了。解决建复合索引KEY idx_device_time (device_id, data_time)让 WHERE 条件里的两个字段都能走索引。SELECT只查需要的列避免SELECT *把raw_json这种大字段也拖出来IO 开销会小很多。5.2 批量插入偶发失败撞上 max_allowed_packet现象上报接口平时正常每到采集器集中补报时就偶发 500日志里有PacketTooBigException。原因一次 POST 里塞了几千条数据MyBatis 的 foreach 拼出一条超大的 INSERT 语句超过了 MySQL 服务端允许的最大包大小。解决在代码里按固定大小切批比如每 500 条提交一次JDBC URL 加上rewriteBatchedStatementstrue。顺手把 MySQL 的max_allowed_packet从默认值调大一点也可以但切批才是根治办法。5.3 告警风暴缺状态位与唯一约束现象同一块电表功率超限后每隔一分钟插入一条新告警几分钟之内告警列表刷了上百条。原因alarm_record表没有唯一约束判定逻辑里也没有“该设备是否已经在告警中”的检查每轮定时任务都当成新告警插入。解决给告警记录表加唯一索引(rule_id, device_id, point_code, status)其中status1表示未恢复。插入时用INSERT ... ON DUPLICATE KEY UPDATE更新告警时间不重复插入。等数据回到阈值以内再启动一批恢复任务把status置为 0记录end_time。5.4 前端说“第一页是空的”页码约定不一致现象前端打开能耗报表页码显示 1表格一条数据都没有但接口返回的total明明有值。原因前端分页组件发出的参数是current和pageSize后端接口要求的是pageNum和pageSize字段对不上后端拿到current后默认当成 0 处理查出来第一页是空集合。PageHelper 的页码从 1 开始如果前端从 0 开始还能查出第二页和第一页重叠这种更隐蔽的问题。解决接口文档先定字段名Controller 入参显式写RequestParam(pageNum) Integer pageNum并且用Min(1)校验小于 1 直接报参数错误。前端联调时第一件事是打开开发者工具看网络请求的 Query String跟接口文档对一遍字段名。6. 让答辩和复用都更稳的进阶配置缓存热点统计与部署内存调优能耗看板是每次演示都会被第一个点开的页面它要返回今天的实时功率、本月累计用量、环比变化这些聚合数据。这类接口的特点是数据变化不频繁但前端监控页每隔几秒轮询一次每个轮询打到数据库上做 GROUP BY 聚合有点浪费。常见做法是给这个接口加一层本地缓存或 Redis 缓存TTL 设为 60 秒。能耗数据本身就是分钟级入库60 秒的延迟在业务上完全感知不到但能把数据库的聚合压力降一个数量级。GetMapping(/dashboard) Cacheable(cacheNames energy:dashboard, key #buildingId, unless #result null) public ResultDashboardVO dashboard(Long buildingId) { // 查询今日功率曲线、本月用电、环比数据 return Result.success(dashboardService.summary(buildingId)); }用 Spring Cache 时记得给缓存管理器配置统一的过期时间不要依赖默认值。部署阶段也有一个不起眼但致命的参数如果服务器只有 1G 内存跑 MySQL 加 Java 进程很容易 OOM。我用宝塔面板部署这类 Java 项目时一般把启动参数里的-Xms512m -Xmx512m固定住不让 JVM 在内存紧张时扩容失败同时把 MySQL 的innodb_buffer_pool_size调到物理内存的一半以内。内存分配这件事看起来土但答辩现场最怕的就是演示到一半进程被系统杀掉。最后说一个我自己的教训每次拿到这种毕设后端包第一步永远先改数据库连接串第二步跑起来看日志里的 SQL 打印确认表结构能对上。连接串不对导致的黑匣子报错曾经让我在“连接失败”的提示前卡了大半天后来才意识到密码里的特殊字符没做 URL 编码。这种小坑不会写在任何文档里但一次就能记住。希望帮到你。本文还有配套的精品资源点击获取