简介：面向城市能源管理场景的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是电表网关的IP，unitId是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 ) ENGINE=InnoDB COMMENT='能耗设备档案表';InfluxDB这边的设计重点是measurement和tag。我们用energy_meter作为measurement，tag用device_no和meter_type，field用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天"); } List<EnergyPoint> 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(host='127.0.0.1', user='root', password='', database='energy_mgr') cursor = db.cursor() cursor.execute("SELECT rule_id, device_no, alarm_type, threshold, duration FROM alert_rules WHERE is_active=1") 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 = f"SELECT 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.profile=prod java -jar energy-backend-1.0.0.jar --spring.profiles.active=prod需要注意的坑：打包出的jar里如果包含了dev配置的明文密码，泄露风险很大。我后来改用配置中心的方式，敏感信息从环境变量里读，jar包里只留占位符。还有一个坑是时区，JVM默认时区可能和InfluxDB不同，启动时加-Duser.timezone=Asia/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的写入会有大量磁盘IO，MySQL如果也在同一块盘，可能会出现查询超时。我建议分开部署，或者至少给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(url="http://localhost:8086", token="your-token", org="energy-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(bucket=bucket, 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的端口拦了。从那以后我每次部署都强制走一遍端口连通性检查，再加一条时区校验。希望这篇拆解能帮你少踩几个同样的坑，系统能稳稳跑起来。
本文还有配套的精品资源，点击获取
