简介智慧城市大气环境监测系统是一个基于Vue.js的前端实战项目面向智慧城市方向学习者和初中级前端开发人员用于构建集环境数据采集、分析、展示于一体的可视化平台。项目覆盖空气质量指数、PM2.5、SO2、NOx、臭氧等指标的实时监测并引入人工智能算法进行污染趋势预测与异常告警可帮助理解物联网接入、数据处理和前端交互的完整实现思路。压缩包共38个文件以Vue组件、JavaScript脚本、JSON配置和PNG界面资源为主体另有少量SCSS样式及HTML入口文件整体体积约7.05MB结构紧凑适合作为课程设计或毕设参考。目前已有216人学习说明该示例具备一定的通用参考价值。通过主控制面板模块可以重点研读Vue路由组织、组件通信、数据可视化图表封装等关键代码结合界面效果图能够快速还原智慧城市大气监测场景适合用于技术练手、项目演示或二次功能扩展。1. 智慧城市大气环境监测系统.zip先解压看架构再谈部署在环境监测类项目的交付物里智慧城市大气环境监测系统.zip 这类压缩包出现的频率比很多人想象得高。它一般不是一个能双击运行的软件而是一整套方案的载体设备接入解析、时序数据存储、告警计算、可视化大屏、部署脚本全都在里面。拿到手第一件事不是急着找 exe而是先解压、看目录、认技术栈再沿着数据链路逐层验证。这篇笔记就是照着这个顺序来的——适合刚拿到交付包的实施工程师也适合打算二次开发或做技术选型的人。2. 拆开数据链路从传感器报文到时序入库的完整实现2.1 这类系统数据从哪来先搞清设备和协议大气环境监测系统的数据源头通常是分布在城市各区域的空气质量微型站和国控站。微型站里挂着 PM2.5、PM10、SO2、NO2、CO、O3 传感器外加温湿度、风速风向。这些传感器通过 RS485 总线接到现场数采仪数采仪再走 4G DTU 或者有线网络把数据上报到中心端。通信协议上RS485 链路最常用 Modbus RTU走 TCP 或 MQTT 的也不少具体看设备厂商。我一般拿到这类 zip 包后会先翻/docs下的设备协议文档确认两件事一是寄存器地址表二是上报格式。Modbus RTU 的数据帧结构非常固定站地址 1 字节、功能码 1 字节、数据区 N 字节、CRC16 校验 2 字节。比如读保持寄存器用功能码 0x03返回帧里第二字节是后续数据字节数。这里最容易翻车的地方是字节序——寄存器值是大端传输而 CRC 校验本身又是小端存储解析时一搞反就是天文数字。2.2 用 Python 写一个 Modbus RTU 帧解析器理解了帧结构写解析器就是照格式拆包的问题。下面这段代码可以处理最常用的读寄存器响应帧带 CRC 校验。真实项目里我会在它外面再套一层串口或者 Socket 读取但核心解析逻辑就是这个。import struct def crc16_modbus(data: bytes) - int: 计算 Modbus CRC16初始值为 0xFFFF多项式 0xA001。 crc 0xFFFF for b in data: crc ^ b for _ in range(8): if crc 0x0001: crc (crc 1) ^ 0xA001 else: crc 1 return crc def parse_modbus_03(packet: bytes) - dict: 解析 0x03 读保持寄存器的响应帧。 帧格式: 站地址(1) 功能码(1) 字节数(1) 寄存器数据(N) CRC(2) if len(packet) 5: raise ValueError(f帧太短: {len(packet)} 字节) addr, func, byte_count packet[0], packet[1], packet[2] data packet[3:3 byte_count] crc_recv struct.unpack(H, packet[-2:])[0] crc_calc crc16_modbus(packet[:-2]) if crc_recv ! crc_calc: raise ValueError( fCRC 校验失败: 接收 {crc_recv:#06x}, 计算 {crc_calc:#06x} ) # 寄存器数据按大端读每 2 字节为一个寄存器值 values [] for i in range(0, len(data), 2): values.append(struct.unpack(H, data[i:i 2])[0]) return {station_addr: addr, func: func, values: values} # 构造一帧测试数据: 站地址 0x01, 功能码 0x03, 返回 1 个寄存器, 数据 0x012C body bytes([0x01, 0x03, 0x02, 0x01, 0x2C]) frame body struct.pack(H, crc16_modbus(body)) print(parse_modbus_03(frame))这段代码最后先自己拼了一帧合法的测试帧这样跑起来必定通过方便你验证解析器本身没写错。逻辑上要理解三个参数byte_count决定了要切多少字节出来寄存器值全部按大端H解析而 CRC 在帧尾是按小端H存放的。解析出来0x012C是十进制 300具体代表多少浓度要看协议文档里的量程和分辨率常见做法是除 10 得到 30.0 µg/m³。很多设备还支持浮点寄存器那就需要用f替代H但帧长度会变为 4 字节一个寄存器别搞混。2.3 时序数据落库表结构设计与选型理由解析出来的数据是典型时序数据一个站、一分钟一条、几十个指标列。存储方案我一般按规模分三档。几百个站以内用 MySQL 或 PostgreSQL 按月分表就够了部署简单实施团队都会上千个站、每秒都有上报的场景上 TDengine 或 InfluxDB压缩率高、聚合查询快。很多智慧城市项目最初图省事全塞 MySQL结果一年后单表几千万行查询大屏直接卡死。如果交付包里用到 MySQL一个满足基本查询需求的建表语句长这样CREATE TABLE air_quality_data ( id BIGINT AUTO_INCREMENT PRIMARY KEY, station_id VARCHAR(32) NOT NULL, ts BIGINT NOT NULL COMMENT 采集时间Unix 毫秒时间戳, pm25 DECIMAL(8,1), pm10 DECIMAL(8,1), so2 DECIMAL(8,1), no2 DECIMAL(8,1), co DECIMAL(8,2), o3 DECIMAL(8,1), temp DECIMAL(5,1), humidity DECIMAL(5,1), KEY idx_station_ts (station_id, ts) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有几个值得说的设计决策。station_id和ts联合索引是这套系统的核心查询路径大屏按站查曲线、按区域查实时值都走这个索引。时间戳我坚持存毫秒整数而不是DATETIME原因后面避坑章节会展开——它能彻底绕开时区转换的麻烦。浓度字段用DECIMAL而不是FLOAT因为浮点比较在告警判定时容易出现边界误差比如 99.9999 和 100.0 之间的诡异差异。数据入库建议走批量写入不要一条一条 INSERT。可以用 MyBatis 的foreach或者 JDBC 的addBatch每 30 秒攒一批把一次上报的几十个站数据一次写进去。这样数据库压力能小一个量级也方便做去重——以(station_id, ts)为唯一键重复上报直接忽略。3. 核心算法与告警AQI 计算为何不能图省事3.1 AQI 分档规则与 IAQI 插值公式AQI空气质量指数是整个系统最容易被做错、又最容易被用户一眼看穿的部分。国标 HJ 633-2012 规定AQI 取各污染物 IAQIIndividual Air Quality Index单项空气质量指数的最大值而不是简单加权平均。每个污染物的 IAQI 按浓度区间线性插值得到。以 PM2.5 实时浓度为例分段表长这样浓度下限 (µg/m³)浓度上限 (µg/m³)IAQI 下限IAQI 上限03505035755010075115100150115150150200150250200300250350300400350500400500IAQI 的插值公式也是线性的当浓度 C 落在某个区间 [BPlow, BPhigh] 内对应 IAQI 区间 [IAQIlow, IAQIhigh]则 IAQI (IAQIhigh - IAQIlow) / (BPhigh - BPlow) * (C - BPlow) IAQIlow。这个公式看着简单但有两个细节必须留意。第一国标对不同污染物有“平均时间”要求。PM2.5、PM10 可以用实时浓度折算也可用 24 小时滑动均值折算两者算出的 AQI 含义不同。实时 AQI 是“现在这一刻的水平”日均 AQI 是“今天整体的水平”展示时必须明确标注口径否则用户拿国控站 App 的数值来对比怎么对都对不上。第二超出上限时不能直接报 500 了事规范里规定超过 500 就归为“爆表”系统里应该走重污染流程而不是参与常规插值。3.2 一份可复制的 AQI 计算与告警判定代码下面是 PM2.5 单项 IAQI 的计算函数以及综合 AQI 计算和告警等级判定。这个实现我只列了 PM2.5 一个污染物的分段表其余污染物照同样模式补齐即可。PM25_BP [ (0, 35, 0, 50), (35, 75, 50, 100), (75, 115, 100, 150), (115, 150, 150, 200), (150, 250, 200, 300), (250, 350, 300, 400), (350, 500, 400, 500), ] def calc_iaqi(concentration: float, bp_table: list) - int: 按分段表线性插值计算单项 IAQI。 for blow, bhigh, ilow, ihigh in bp_table: if concentration bhigh: return round( (ihigh - ilow) / (bhigh - blow) * (concentration - blow) ilow ) return 500 def calc_aqi(pm25: float, pm10: float, so2: float, no2: float, co: float, o3: float) - tuple: 返回 (最大 IAQI, 首要污染物名称)。 items { PM2.5: calc_iaqi(pm25, PM25_BP), PM10: calc_iaqi(pm10, PM10_BP), SO2: calc_iaqi(so2, SO2_BP), NO2: calc_iaqi(no2, NO2_BP), CO: calc_iaqi(co, CO_BP), O3: calc_iaqi(o3, O3_BP), } return max(items.items(), keylambda x: x[1]) def judge_level(aqi: int) - str: if aqi 200: return 重度污染 elif aqi 150: return 中度污染 elif aqi 100: return 轻度污染 elif aqi 50: return 良 return 优 aqi, primary calc_aqi(85, 110, 20, 60, 1.2, 140) print(aqi, primary, judge_level(aqi))calc_iaqi的核心在round国标对 IAQI 要求四舍五入取整不能直接截断否则会出现 74.9 的浓度算出来 99而 75.0 算出来 100 的跳变。max(items.items(), keylambda x: x[1])返回的是首要污染物和它的 IAQI这就是正式发布口径里的 AQI 值。CO 的分段表单位是 mg/m³其他都是 µg/m³建表常量时注意别抄错。3.3 告警噪声抑制持续时长与死区阈值算出了 AQI告警逻辑才刚开始。直接拿每一条实时值去触发告警一定会被骂——污染物浓度本身就在波动夜里微风一吹 PM2.5 在 99 和 105 之间来回抖黄色告警就会反复触发、恢复、再触发。我一般会引入两个机制。第一个是持续时间确认某个等级必须连续 N 分钟常见取 5 分钟都达到该等级才真正推送告警同样恢复也要连续 N 分钟低于解除阈值才解除告警。第二个是迟滞hysteresis区间也就是死区比如黄色告警是 AQI≥100但解除要等 AQI 降到 90 以下。这个“下探 10 个点”的迟滞量能避免浓度在阈值附近抖动时告警状态反复横跳。这两个机制用状态机实现最清晰不要用一堆 if 嵌套。每个站点维护一个状态对象记录当前等级、首次达到时间、上次推送时间。上报数据到达时只更新状态由调度任务检查是否需要切换。这个设计在告警量大的场景意义尤其明显一个城市几百个站每站每分钟一条数据如果没有状态机告警服务和消息推送都会被重复事件打满。4. 可视化与接口让数据上大屏4.1 大屏选型ECharts 地图散点加时序曲线智慧城市项目的大屏需求高度相似一张城市地图打底站点位置用散点标注点的大小和颜色反映污染程度点击站点弹出曲线面板展示最近 24 小时 PM2.5、AQI 变化。这套交互用 ECharts 的 geo 地图 scatter 系列就能实现没有必要上 Cesium 或 WebGIS 引擎。原因很现实大气监测只有几十上百个点不是连续面状数据轻量方案维护成本低得多。后端接口设计也要跟着大屏的刷新模式走。实时面板每 30 秒轮询一次取各站最新一条数据趋势曲线按小时维度聚合查最近 24 小时。这两类查询对应两个独立接口不要让前端为了画趋势图把原始明细全部拉下去——几百个站、24 小时、每 5 分钟一条那就是几万行 JSON浏览器直接卡死。4.2 前端关键配置色阶、轮询与接口约定ECharts 地图散点部分的核心配置如下逻辑和参数我拆开说明。const stations [ { name: 朝阳站, lng: 116.45, lat: 39.92, pm25: 45, aqi: 68 }, { name: 海淀站, lng: 116.30, lat: 39.96, pm25: 120, aqi: 170 } ]; function getAqiColor(aqi) { if (aqi 50) return #00E400; if (aqi 100) return #FFFF00; if (aqi 150) return #FF7E00; if (aqi 200) return #FF0000; return #99004C; } option { geo: { map: china, roam: true, zoom: 4.2 }, series: [{ type: scatter, coordinateSystem: geo, data: stations.map(s ({ name: s.name, value: [s.lng, s.lat, s.pm25, s.aqi] })), symbolSize: val 12 val[2] / 5, label: { show: false }, itemStyle: { color: params getAqiColor(params.value[3]) } }] };coordinateSystem: geo是把散点绑到地图上的关键没有这一行数据只会落在直角坐标系里。value数组的约定是 [经度, 纬度, 附加维度, 附加维度]后面两项可以在symbolSize和itemStyle.color的回调里随意取用。我习惯把 PM2.5 放在第三位、AQI 放第四位这样点的大小反映污染浓度颜色反映空气质量等级视觉语义清晰。getAqiColor的颜色值对应国标 AQI 等级色阶这个是从环保部发布规范里定的标准色不要自己改成渐变色用户不认。轮询刷新用setInterval每 30 秒调一次。我自己实际项目里会加一个页面可见性检测大屏切到后台标签页时暂停请求切回来再立刻刷新。这个优化能显著减少无效请求因为投到拼接屏上的大屏页面经常一开就是一天轮询停不掉的话后端会持续收到大量无效查询。4.3 后端接口返回结构约定前后端联调时接口格式混乱是拖进度的大头。我在交付包里通常会和前端约定一套统一的返回外壳所有接口共用{ code: 0, msg: success, data: { stationId: BJ001, ts: 1720000000000, aqi: 68, pm25: 45, primaryPollutant: PM2.5 } }code用 0 表示成功非 0 表示业务错误msg负责携带错误信息。一个容易忽略的点是ts必须统一用毫秒时间戳并且明确标注时区。前端拿到后直接用new Date(ts)渲染不要再做任何字符串解析和时区偏移这样前后端各算各的时区导致曲线错位的坑就能从根上堵住。5. 部署运行避坑5 个让系统翻车的常见问题5.1 现象AQI 曲线每天固定偏移 8 小时大屏上的污染曲线在下午 2 点出现峰值但国控站数据显示峰值在早上 8 点而且每天都是整体平移 8 小时。查数据发现库里的时间戳和真实采集时间差了一个时区。原因设备厂商的采集程序用的datetime.now()取的是北京时间而部署 MySQL 的服务器时区是 UTC或者后端连接串里没指定时区。等于数据写入时按 UTC 解释了一次查询展示时又按本地时间解释了一次一来一回就错了 8 小时。解决时间戳全部统一存 Unix 毫秒整数展示时由前端按浏览器时区转。数据库层面在 MySQL 连接串里显式加serverTimezoneAsia/ShanghaiJDBC 驱动或use_timezoneTruetimezone08:00Python 驱动。后端取当前时间统一int(time.time() * 1000)不经过任何DATETIME转换入库。5.2 现象PM2.5 数值长期偏低设备自检却正常某站的 PM2.5 数据连续一周比同区域国控站低 20% 以上设备远程自检显示传感器工作正常。现场运维确认设备没断网、没报警。原因这是典型的传感器零点漂移加采样口污染。PM2.5 传感器用的是光散射原理长期运行后光学镜片积尘、激光器衰减读数逐步偏低这种漂移自检发现不了。另一个常见因素是进气口的切割头没按时清洗大颗粒堵了之后小颗粒采样量也受影响。解决给系统加一个数据质量分析任务每 24 小时把每个站的数据和周边站做比对如果持续偏差超过 30% 就自动生成校准工单。设备侧要求运维按季度做零点校准和流量校准。这类问题靠软件逻辑能提前发现别等用户拿国控站数据来对时才追查。5.3 现象告警凌晨频繁误报白天反而安静黄色告警集中在凌晨 2 点到 5 点触发每次持续十几分钟就自动恢复白天很少告警。排查发现后半夜扩散条件差PM2.5 浓度在 99 到 105 µg/m³ 之间波动恰好卡在黄色告警阈值 AQI100 对应的浓度线附近告警状态来回切换。原因阈值判定没有迟滞机制也没有持续时间要求。浓度不是稳定超过阈值而是短时间内上下穿越系统每次都当成一次新的告警事件。解决按 3.3 节的方案加“连续 5 分钟达到等级才触发、AQI 降到 90 以下才解除”的状态机逻辑。实施后误报量直接降了八成。注意迟滞量不要设太大否则真实污染过程会被延长告警时间掩盖。5.4 现象Docker 部署后容器内服务时间与宿主机不一致用 Docker Compose 部署宿主机是北京时间但容器里date命令显示 UTC 时间。告警判断依赖“凌晨”这类时段逻辑时行为完全错乱。原因Docker 容器默认使用 UTC 时区宿主机的时间不会自动传进去。Java 或 Python 进程如果调用系统时区函数取当地时间拿到的就是北京时间减 8 小时。解决部署时统一处理在 Compose 文件里给每个服务加两行environment: - TZAsia/Shanghai volumes: - /etc/localtime:/etc/localtime:ro同时把时间戳规范改成毫秒整数时区只影响日志和人工排障不再影响业务数据。5.5 现象zip 解压后中文乱码、启动脚本报路径错从某个实施方手里拿到的 zip 包在 Windows 上用默认解压工具解开后配置文档目录变成了一串乱码启动脚本里的相对路径全部找不到但文件确实都在。原因zip 包是在 Linux 下打的文件名是 UTF-8 编码Windows 自带的解压工具按本地 ANSIGBK解码文件名就乱了。这种情况在“智慧城市大气环境监测系统.zip”这类跨平台交付的包里太常见了。解决Windows 上先装 7-Zip 或 Bandizip解压时看有没有编码选项Linux 上解决更干净用unzip -O GBK强制按 GBK 解压或者直接在 Linux 下zip -r重新打包成 UTF-8。我自己的习惯是交付前统一在 Linux 下打包并在 README 里写明解压工具省得实施现场花半小时代理解码问题。6. 交付前的最后一步模拟数据联调与性能抽查6.1 用 30 分钟跑通一路伪造站点数据很多系统翻车不在代码在没人真正把一条数据从上报接口走到大屏。交付前我会拉一个模拟数据源往上报接口灌 30 分钟数据把整条链路激活。import time import random import requests url http://localhost:8080/api/data/report station {stationId: TEST001, lng: 116.39, lat: 39.91} for i in range(360): payload { stationId: station[stationId], timestamp: int(time.time() * 1000), pm25: round(random.uniform(25, 180), 1), pm10: round(random.uniform(30, 220), 1), so2: round(random.uniform(5, 50), 1), no2: round(random.uniform(10, 90), 1), co: round(random.uniform(0.3, 2.5), 2), o3: round(random.uniform(60, 200), 1), temp: round(random.uniform(18, 30), 1), humidity: round(random.uniform(40, 80), 1) } resp requests.post(url, jsonpayload, timeout5) if resp.status_code ! 200: print(f第 {i} 条上报失败: {resp.text}) break if i % 50 0: print(f已上报 {i} 条最近一条 AQI 相关数据: {payload[pm25]}) time.sleep(5)这段脚本每 5 秒上报一条跑 30 分钟共 360 条。timestamp用int(time.time() * 1000)保证和线上逻辑一致——很多联调问题都是模拟脚本自己写错了时间戳导致的。6.2 验证清单从入库到告警的逐项检查表模拟数据跑起来后按下面的清单逐项核对不要只看大屏有没有点。检查项操作方法预期结果数据入库进数据库执行SELECT COUNT(*) FROM air_quality_data WHERE station_idTEST001数量每 5 秒增加30 分钟后累计 360 条AQI 计算准确性取一条 pm2585 的数据手算 IAQI 再和接口返回对比接口返回 107~108且 primaryPollutant 为 PM2.5告警触发把模拟脚本的 pm25 改为 260持续跑 6 分钟约 5 分钟后收到黄色以上告警且只有一条推送大屏展示浏览器打开大屏页面定位到 TEST001 站散点颜色为黄色或橙色点击弹出曲线且峰值与模拟参数吻合时区验证在库里查该站最新记录的时间换算成北京时间与本地当前时间误差在 1 秒以内我最早做这类项目时觉得大屏能亮就是交付成功结果用户拿国控站数据一比就翻车查了一整天发现是聚合脚本里把毫秒当秒用了。后来学乖了每次交付前先跑一遍这张表半小时换一夜安稳。希望帮到你。本文还有配套的精品资源点击获取