简介面向城市能源管理场景的Web前端资源包基于Bootstrap框架构建整套系统界面具备良好的响应式布局可在桌面与移动设备上顺畅访问适合课程设计、毕业设计或企业能源监控项目作为前端参考。资源共170个文件压缩包仅3MB包含64个png界面截图、18个html页面、18个js交互脚本以及css/scss/less样式、字体图标和db数据库文件目录结构清晰便于按功能模块检索。系统核心覆盖登录验证、主控仪表盘、实时能耗监测、异常响应预警、设备入库检修与查询等环节借助图表直观呈现电力、燃气、用水等资源用量帮助管理人员及时发现异常消耗并做出策略调整登录页还提供清晰的输入提示、错误反馈和忘记密码入口体贴用户操作体验。已有899人学习下载适合需要快速搭建能源管理Web界面、理解Bootstrap响应式布局或完善系统前端功能的中级开发者也可作为前后端结合的完整实训参考。1. 基于Web的城市能源管理系统从设备数据到决策看板的最后一公里某园区能源管理项目里真正让甲方点头的不是我们接了多少块电表而是Web端那个能钻取到每层楼每块表的能耗看板。所谓城市能源管理系统就是把分散在楼宇、工厂、公共设施里的水电气暖数据统一采集、清洗、存储再通过浏览器端实时展示与分析的一套Web平台。它解决的核心问题是能耗数据散、统计口径乱、告警滞后适合园区运维方、物业公司、公共机构能源管理员也适合做智慧城市配套的开发者。本文从架构、代码、部署到踩坑完整拆解这个系统的落地方案。2. 整体架构与数据链路从Modbus到浏览器页面要过几道关2.1 设备接入层协议适配与数据规范化城市能源管理系统的数据源是五花八门的现场设备最常见的是电表、水表、气表和楼宇控制器DDC。电表大多走Modbus RTU/TCP协议热力表走DL/T 645部分能耗采集器支持MQTT直接上送JSON。我们团队接手时现场设备品牌超过六种协议各不相同所以第一道关不是写业务代码而是把协议差异挡在接入层外面。我一般用Spring Boot写一个独立的采集服务Energy Collector为每种协议做一个适配器统一封装成内部标准结构。下面是一个基于Modbus TCP读取电表数据的核心示例// ModbusTcpCollector.java import com.serotonin.modbus4j.ModbusFactory; import com.serotonin.modbus4j.ModbusMaster; import com.serotonin.modbus4j.ip.IpParameters; import com.serotonin.modbus4j.locator.BaseLocator; import com.serotonin.modbus4j.msg.ReadHoldingRegistersRequest; import com.serotonin.modbus4j.msg.ReadHoldingRegistersResponse; public class ModbusTcpCollector { private static final int PORT 502; public static double readActivePower(String ip, int unitId, int address, int dataCount) { IpParameters params new IpParameters(); params.setHost(ip); params.setPort(PORT); params.setEncapsulated(false); ModbusFactory factory new ModbusFactory(); ModbusMaster master factory.createTcpMaster(params, true); master.setTimeout(2000); // 超时2秒防止设备无响应阻塞采集线程 master.setRetries(2); // 重试2次弱网环境下提高采集成功率 try { master.init(); ReadHoldingRegistersRequest req new ReadHoldingRegistersRequest(unitId, address, dataCount); ReadHoldingRegistersResponse res (ReadHoldingRegistersResponse) master.send(req); if (res.isException()) { throw new RuntimeException(Modbus exception: res.getExceptionCode()); } short[] shorts res.getShortData(); // 有功功率一般以两字节有符号数存储乘以变比系数得到实际kW double value (shorts[0] 0xFFFF) * getCtRatio(unitId); return value; } catch (Exception e) { // 采集失败时返回NaN由上层服务决定是否补采 return Double.NaN; } finally { master.destroy(); } } private static double getCtRatio(int unitId) { // 实际项目中从设备档案表读取这里返回默认值 return 1.0; } }这段代码有四个参数需要解释。ip是电表网关的IPunitId是Modbus从站地址通常等于电表表号address是寄存器起始地址电表有功功率一般在0x0036附近不同厂家会在说明书里给寄存器映射表。dataCount是读取寄存器个数读一条时是2字节但有些表计会占到两个寄存器。master.init()每个周期执行一次会消耗连接资源我一般改成连接池复用。超时和重试必须设置不然任何一个电表掉线都会拖垮整个采集线程。采集到的数据不能直接入库还要做规范化。设备可能上报的是累积电量需要转成增量有的上报的是千瓦时有的是兆瓦时。我们会先把原始值换算成统一单位kWh和kW再加上meterNo、timestamp、dataSource字段写入Kafka或直接插入时序库。这里有一个经验单位换算和寄存器地址映射一定要写在配置表里不要硬编码否则每换一个设备就要改一次代码。2.2 数据存储层关系库与时序库的分工能耗数据是典型的时间序列数据每秒或每分钟一条一天单表就可能有几十万行。用MySQL硬扛查询会很吃力而且随着时间推移数据膨胀极快。我们采用了双库方案MySQL存设备档案、用户、角色、告警记录、系统配置InfluxDB存时序能耗数据。这种分工让两类数据各得其所。设备档案表结构大致如下CREATE TABLE device_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, device_no VARCHAR(32) NOT NULL COMMENT 设备编号如METER-0001, device_name VARCHAR(64) COMMENT 设备显示名称, location VARCHAR(128) COMMENT 安装位置如A栋3层配电箱, protocol_type VARCHAR(16) COMMENT modbus_tcp / modbus_rtu / mqtt, ip_address VARCHAR(32), port INT DEFAULT 502, unit_id INT COMMENT Modbus从站地址, ct_ratio DECIMAL(10,2) DEFAULT 1.0 COMMENT 变比系数, is_active TINYINT DEFAULT 1, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB COMMENT能耗设备档案表;InfluxDB这边的设计重点是measurement和tag。我们用energy_meter作为measurementtag用device_no和meter_typefield用kwh和kw。Tag索引效率高查询时按设备和时间范围过滤非常快。写入时注意时间戳要统一成UTC存储前端展示时再转本地时区否则不同浏览器用户看到的时段会错位。InfluxDB的retention policy也要设置比如原始数据保留90天聚合成小时级的数据保留两年这能控制磁盘占用和查询速度。2.3 服务层REST API设计与鉴权服务层是Web前端和时序库之间的桥梁。我们设计了若干REST接口实时数据查询、历史曲线、能耗排行、告警记录等。接口用JWT做鉴权按角色控制数据权限比如普通用户只能看自己所在园区的数据。下面是一个查询历史能耗的接口示例// EnergyController.java RestController RequestMapping(/api/v1/energy) public class EnergyController { Autowired private EnergyQueryService energyQueryService; // 查询指定设备在时间范围内的能耗增量单位kWh GetMapping(/history) public Result history(RequestParam String deviceNo, RequestParam long startTime, RequestParam long endTime, RequestParam(required false, defaultValue hour) String interval) { if (endTime - startTime 7 * 24 * 3600 * 1000) { return Result.error(查询时间范围不能超过7天); } ListEnergyPoint points energyQueryService.queryHistory(deviceNo, startTime, endTime, interval); return Result.ok(points); } }这里的interval支持raw、hour、day三种粒度。实时数据量大的时候前端会频繁轮询这个接口所以我在查询层加了Redis缓存对相同参数的结果缓存30秒。注意时间范围限制7天是我和运维同学商量的结果避免用户一次拉取几个月的数据把InfluxDB的查询线程占满。如果是看一年的趋势应该走预聚合表不是查原始数据。3. 核心功能实现能耗聚合、分项统计与告警触发3.1 分项计量把总表数据拆到照明、空调、动力城市能源管理一个重要能力是分项统计一栋楼的总电表下面照明用多少、空调多少、动力多少。分项有两种实现方式一种是每个回路独立装电表直接按表计归属分项另一种是总表只有一个需要按系数拆分。第一种精度高但成本大。第二种在改造项目中常用算法也不复杂。我们用的系数拆分逻辑在系统里配置每个分项的拆分比例默认按建筑类型和季节调节总表增量乘以比例得到分项增量。比例表存MySQL每天凌晨由定时任务根据历史用量重新计算一次避免季节变化导致偏差太大。代码层面聚合查询用InfluxDB的GROUP BY就可以完成SELECT SUM(kwh) FROM energy_meter WHERE time 2025-01-01T00:00:00Z AND time 2025-01-02T00:00:00Z GROUP BY meter_type这条SQL按meter_type照明、空调、动力分组返回每个分项的总和。如果设备在采集时已经打上了分项tag就不用拆系数。这里要特别留意tag的命名统一我在多个项目里见过light和照明混用的情况后端聚合时就会漏数据。我一般会在设备接入时强制校验tag字典不在字典里的直接拒绝入库。3.2 告警规则引擎阈值、环比与累计异常告警是能源管理系统的眼睛。规则可以分成三类绝对阈值超过100kW、环比突增比昨天同时段高50%、连续累计异常连续30分钟超限。规则配置放在MySQL表里定时任务每分钟扫一次。下面是一个简单的规则扫描代码片段# alert_scanner.py - 用Python模拟服务端定时任务 import pymysql import requests import time def scan(): db pymysql.connect(host127.0.0.1, userroot, password, databaseenergy_mgr) cursor db.cursor() cursor.execute(SELECT rule_id, device_no, alarm_type, threshold, duration FROM alert_rules WHERE is_active1) rules cursor.fetchall() influx_headers {Content-Type: application/json} for rule in rules: rule_id, device_no, alarm_type, threshold, duration rule if alarm_type threshold: # 查询最近一分钟的平均功率 query fSELECT MEAN(kw) FROM energy_meter WHERE device_no{device_no} AND time now() - 1m # 这里简化了InfluxDB查询的调用 val query_influx(query, influx_headers) if val and val threshold: send_alert(rule_id, device_no, f功率超限当前{val:.2f}kW) # 环比和累计异常规则省略思路类似 cursor.close() db.close()这段Python只是示意实际生产环境中我建议把这个扫描器写进Java定时任务里因为和Spring的配置中心集成更方便。要注意duration参数它代表持续多久才告警用来滤掉瞬时毛刺。用户在界面上配置的“持续10分钟”不是每10分钟扫一次而是扫描时要检查“最近10分钟都超阈值”这需要时序库的连续窗口计算不能用一个简单阈值判断。告警通知通过WebSocket推送到前端同时落库。如果把所有人手机号都绑上告警风暴很常见所以我们加了告警抑制同一个设备同一条规则30分钟内只发送一次。4. 部署与联调从开发机到生产环境的坑4.1 后端打包与配置外部化开发环境下后端配置写死在application.yml里但到了生产环境数据库地址、InfluxDB地址、告警规则参数都可能不同。我习惯用Spring Boot的Profile配合环境变量来管理多套环境配置。资源文件里放三个配置application-dev.yml、application-test.yml、application-prod.yml启动命令指定profile。打包时用Maven跳过测试命令如下mvn clean package -DskipTests -Dactive.profileprod java -jar energy-backend-1.0.0.jar --spring.profiles.activeprod需要注意的坑打包出的jar里如果包含了dev配置的明文密码泄露风险很大。我后来改用配置中心的方式敏感信息从环境变量里读jar包里只留占位符。还有一个坑是时区JVM默认时区可能和InfluxDB不同启动时加-Duser.timezoneAsia/Shanghai并且统一所有服务用UTC处理时间戳只有展示层转本地时间。4.2 前端构建与Nginx反向代理前端用的是Vue 3 Element Plus构建流程很简单。但真正麻烦的是接口代理和静态资源缓存。开发时通过Vite的proxy处理跨域生产环境用Nginx统一入口。一份典型的Nginx配置如下server { listen 80; server_name energy.example.com; gzip on; gzip_types application/javascript text/css; location /api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_connect_timeout 3s; proxy_read_timeout 30s; } location / { root /opt/energy-web/dist; index index.html; try_files $uri $uri/ /index.html; } }这里有一个很重要的参数proxy_read_timeout 30s。如果时序查询偶尔超过30秒比如大数据量聚合Nginx会中断连接前端会收到504。我后来把聚合类接口单独拆出来超时时间改成120秒普通查询保持30秒。另外try_files $uri $uri/ /index.html解决Vue Router的history模式刷新404问题这个几乎所有单页应用都要注意。4.3 时序库与关系库的物理部署InfluxDB和MySQL可以部署在同一台服务器但要注意资源争抢。能耗采集量大的时候InfluxDB的写入会有大量磁盘IOMySQL如果也在同一块盘可能会出现查询超时。我建议分开部署或者至少给InfluxDB单独一块SSD。InfluxDB的max-concurrent-queries参数默认是0不限高并发查询会把内存打爆我一般设成16并且限制每次查询的最大扫描行数。联调阶段最容易出现的问题不是功能逻辑而是IP/端口映射错误。例如现场设备网关在另一个网段后端采集服务在服务器上但没放开出网规则。所以联调第一步是检查服务器上能否直接访问设备IP:端口用telnet或nc测一遍再启动采集服务。5. 避坑指南城市能源管理系统实施中常见的五个问题5.1 设备时间戳与服务器时区不一致现象前端图表中某台设备数据总是偏移8小时凌晨的曲线跑到下午。 原因设备端本地时间设置为北京时间但后端采集服务按UTC时间戳写入InfluxDB也没有给设备时间做时区转换。 解决采集时统一让设备返回Unix时间戳或UTC时间入库前强制归一化。如果设备只能返回北京时间就在接入层配置timezone_offset_minutes字段写入前减去480分钟。5.2 采集线程阻塞导致后续数据全部延迟现象某台电表断电或网线松动整个采集程序的后续设备查询全部堆积数据延迟越来越严重。 原因Modbus串行采集线程没有隔离一个从站超时导致后续请求排队。 解决改为每个设备或每组设备一个独立线程池超时和重试单独配置。同时采集结果写入本地消息队列即使网络阻塞已读到的数据也能落库。5.3 前端图表时间格式化出错现象浏览器显示的时间和数据库中的时间不一致且不同浏览器显示不同。 原因InfluxDB返回的时间戳是RFC3339 UTC格式前端直接用JavaScript的Date.parse解析本地时区不同显示就不同。 解决后端接口统一返回毫秒时间戳前端用Day.js的utc插件转换成本地时区并在UI上显示时区标识。另外查询参数的时间范围也统一用毫秒时间戳不做字符串传递。5.4 告警风暴把通知服务打爆现象某栋楼停电后全楼所有表计都报告警手机短信被刷屏通知服务宕机。 原因规则没有抑制逻辑每个设备独立告警且没有分组归并。 解决加规则级抑制窗口同一规则同一设备30分钟内只发一次同时增加“园区级”告警如果总表掉线下属分表告警自动延迟10分钟避免从属设备全部报一遍。5.5 报表查询越来越慢现象系统运行两个月后历史查询接口响应时间从200ms变成2秒以上。 原因InfluxDB原始数据无法扛住高频大范围聚合查询且没有建立连续查询Continuous Query。 解决为小时、天两个粒度建立降采样CQ报表页面默认查降采样数据只有钻取到分钟级时才查原始数据。生产环境中原始数据保留30天降采样数据保留24个月查询性能和磁盘占用都能得到控制。6. 进阶验证用模拟数据让系统跑起来并做性能摸底6.1 用Python生成连续模拟数据没有现场设备时我们经常写一个模拟器来测试系统。下面这个脚本按固定频率往InfluxDB写入模拟电表数据用于验证采集、告警和前端联动# simulate_meter.py import time import random from influxdb_client import InfluxDBClient client InfluxDBClient(urlhttp://localhost:8086, tokenyour-token, orgenergy-org) write_api client.write_api() bucket energy_bucket device_no METER-SIM-001 while True: kw random.uniform(20, 85) # 模拟功率20~85kW kwh_increment kw / 60.0 # 按分钟产生电量增量 point { measurement: energy_meter, tags: {device_no: device_no, meter_type: lighting}, fields: {kw: round(kw, 3), kwh: round(kwh_increment, 6)}, time: time.time_ns() } write_api.write(bucketbucket, record[point]) time.sleep(60) # 每分钟一条脚本关键点kw和kwh同时写入kw用于实时曲线kwh用于累计增量查询。meter_type标成lighting方便测试分项聚合。写入频率默认60秒如果想压测采集性能可以改成1秒但注意InfluxDB的1分钟数据点数量会暴增建议用专用influx实例跑压测。6.2 查询接口性能摸底用模拟数据跑两周以后可以检查历史查询接口在数据量达到百万级时的表现。我习惯用explain命令查看InfluxDB的查询计划重点确认查询是否命中了时间索引和tag索引。压测可以用JMeter或简单的Python并发脚本这里给一个经验3000个设备、每分钟一个点一小时数据总量是18万点跑小时级聚合查询应该在1秒内完成如果超过3秒优先检查查询过滤条件里是否带了device_no不带设备维度的全表聚合在大数据量下几乎必然慢。另外一个验证技巧是故意断掉模拟器几分钟再恢复然后观察断点数据是否被补采。很多系统的采集服务在网络恢复后不会自动补历史数据导致曲线出现空洞。我们会在采集层记录last_success_time恢复后按时间差补采这是一个容易被忽略但很加分的功能。我至今记得某次联调现场所有功能都正常唯独告警不推送。查了两小时最后发现是服务器防火墙把WebSocket的端口拦了。从那以后我每次部署都强制走一遍端口连通性检查再加一条时区校验。希望这篇拆解能帮你少踩几个同样的坑系统能稳稳跑起来。本文还有配套的精品资源点击获取