Java空气质量监测管理系统解析：从Spring Boot到AQI计算

简介：面向Java学习者及环境监测项目开发者，这套空气质量监测信息管理系统源码包提供了一个前后端完整的参考实现。系统涵盖数据采集、数据库存储、前端展示等典型模块，有助于快速理解基于Java Web的分层架构与前后端交互逻辑，也适合作为毕业设计或课程设计的蓝本。资源包共217个文件，以XML配置文件、GIF图片、JavaScript脚本和Java源文件为主，同时包含少量CSS、HTML页面及一份PDF说明文档，整体覆盖后端业务逻辑、界面资源、项目配置和使用说明，压缩后仅845KB，结构清晰便于定位。目前已有287人学习下载。通过源码和文档，可以学习到监测设备通信接口的编写、PM2.5等空气质量指标的清洗与入库过程，以及基于LayUI的管理界面实现方式；配套文档还介绍了数据库表设计和系统部署要点，帮助理解完整业务流程并支持二次开发，对课程设计或实际项目均具有参考价值。

1. Java 空气质量监测管理系统：先从压缩包名读懂交付物

拿到一个基于java空气质量监测信息管理系统源码带文档.zip，第一件事不是解压，而是判断它属于哪类交付物。这类压缩包最常见是高校软件工程课设、毕业设计或实训项目的导出包，命名里“源码带文档”五个字才是关键：它默认接收方需要同时拿到可运行的代码、可见的数据库脚本、以及能讲清楚设计过程的文档，而不是一个能扫码即用的 SaaS 产品。对 Java 从业者来说，这类包既是面试时讲项目经验的素材，也是快速熟悉一套标准业务系统结构的入口。整个工程的业务主线其实只有一条：空气质量监测点上报污染物浓度数据，后台管理端维护站点、录入监测值、计算空气质量指数 AQI 并展示给用户。本文按“选型与设计、核心实现、文档组织、部署排错”这条路径把它拆开，所有方案都是做这类管理系统最常见、最不容易被问倒的做法。

2. 技术选型与数据库设计：空气质量监测系统先定框架还是先定表

2.1 框架怎么选：Spring Boot + MyBatis 还是 SSM

我在处理这类 Java 管理系统源码时，第一步永远是确认工程是基于 Spring Boot 还是传统 SSM。前者内嵌 Tomcat，打完 jar 包直接java -jar跑起来；后者要外置 Servlet 容器并手动配置 Spring 和 MyBatis 的 XML。从交接和答辩角度看，Spring Boot 明显省事，但传统 SSM 项目在“文档完整性”上往往写得更多，因为课设模板要求你画出完整的 Spring 配置流程。

无论哪种栈，业务层写法高度相似：Controller接收前端请求，Service层处理统计计算逻辑，Mapper层对应 SQL 操作。我一般建议优先用 Spring Boot，理由不是新技术一定好，而是它把部署环节的不确定性降到最低。很多源码包跑不起来，问题恰恰出在 Tomcat 版本与 JDK 不匹配上，Spring Boot 内嵌容器能避开这一半的坑。

2.2 空气质量业务的数据表怎么设计：站点、监测数据与 AQI 计算依据

这类系统的数据库设计通常围绕三张核心表展开。第一张是监测站点表，记录站点名称、区域、经纬度；第二张是污染物监测数据表，保存每个站点每天多次采样的浓度值；第三张是用户表，承担后台登录和权限校验。设计时最容易忽略的是把 AQI 计算中间结果单独落表，这会导致每次展示都要全量重算。

CREATE TABLE `t_monitor_site` ( `id` INT NOT NULL AUTO_INCREMENT, `site_name` VARCHAR(50) NOT NULL COMMENT '站点名称', `area_name` VARCHAR(30) DEFAULT NULL COMMENT '所属区域', `longitude` DECIMAL(10,6) DEFAULT NULL COMMENT '经度', `latitude` DECIMAL(10,6) DEFAULT NULL COMMENT '纬度', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `t_air_quality` ( `id` INT NOT NULL AUTO_INCREMENT, `site_id` INT NOT NULL COMMENT '站点ID', `pollutant_code` VARCHAR(10) NOT NULL COMMENT '污染物编码: PM25/PM10/SO2/NO2/CO/O3', `concentration` DECIMAL(10,2) NOT NULL COMMENT '实测浓度值', `monitor_time` DATETIME NOT NULL COMMENT '监测时间', PRIMARY KEY (`id`), KEY `idx_site_time` (`site_id`, `monitor_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里pollutant_code加字符串编码而不是拆成六列，是因为不同污染物的采样频率和计算时段不同，拆成宽表会让写统计 SQL 时非常别扭。索引idx_site_time是查询每天平均浓度、计算 AQI 的常用路径，务必加上。concentration用DECIMAL(10,2)而不是FLOAT，是为了避免 MySQL 浮点比较时出现0.30000000000000004这类问题。

2.3 文档里的 ER 图如何映射到代码目录

文档中画好的 ER 图，落到代码里就是 entity、mapper、service、controller 四层目录。我拿到这种项目源码，会先看三件事：entity里的字段注释是否与数据库字段注释一致、mapper.xml里的 resultMap 是否漏了字段、Service实现类里事务注解是否加在公开方法上。这是一套排查逻辑，也很可能是答辩现场老师问“你的项目分层体现在哪里”时的标准回答路径。

3. 核心功能实现：空气质量数据录入、AQI 计算与可视化

3.1 监测数据录入：批量插入是这类系统最重要的细节

空气质量监测数据的录入通常是定时任务或数据接口批量推送，一个站点一天会产生多次采样记录。如果写成单条插入，数据量一上去性能立刻崩。常见做法是 MyBatis 的批量insert，配合ExecutorType.BATCH或者直接拼接多值 SQL。

public int batchSaveSiteData(List<AirQualityDO> dataList) { if (CollectionUtils.isEmpty(dataList)) { return 0; } return airQualityMapper.batchInsert(dataList); }

<insert id="batchInsert" parameterType="list"> INSERT INTO t_air_quality (site_id, pollutant_code, concentration, monitor_time) VALUES <foreach collection="list" item="item" separator=","> (#{item.siteId}, #{item.pollutantCode}, #{item.concentration}, #{item.monitorTime}) </foreach> </insert>

foreach拼接多值 SQL 在数据量小时最直观，但注意 MySQL 对单条 SQL 的长度有限制，max_allowed_packet默认一般是 64MB，通常够用。如果数据列表超过几千条，按 200 条一批分批提交，否则会报PacketTooBigException。逻辑上还要做一步判断：同一站点同一时刻同一污染物的重复数据如何处理，是覆盖还是跳过。业务上应该跳过，保留首次采集值，防止定时任务重复推送造成污染。

3.2 AQI 计算：用 IAQI 分段插值而不是简单求平均

空气质量指数 AQI 是整个系统里最有技术含量的计算模块。AQI 不是直接把六种污染物浓度相加，而是先对每种污染物计算 IAQI（Individual Air Quality Index），再取最大值。IAQI 的计算公式是分段线性插值：

IAQI = ((IAQI_Hi - IAQI_Lo) / (BP_Hi - BP_Lo)) × (C - BP_Lo) + IAQI_Lo

public class AqiCalculator { // PM2.5 24小时平均浓度对应的IAQI分段, 浓度上限和指数上限成对出现 private static final int[] PM25_BP = {0, 35, 75, 115, 150, 250, 350, 500}; private static final int[] IAQI_LEVEL = {0, 50, 100, 150, 200, 300, 400, 500}; public static int calculateIAQI(double concentration, int[] bpLow, int[] iaqiLow) { if (concentration <= 0) { return 0; } for (int i = 1; i < PM25_BP.length; i++) { if (concentration <= PM25_BP[i]) { double bpHigh = PM25_BP[i]; double bpLowVal = PM25_BP[i - 1]; int iaqiHigh = IAQI_LEVEL[i]; int iaqiLowVal = IAQI_LEVEL[i - 1]; return (int) Math.round( (iaqiHigh - iaqiLowVal) * 1.0 / (bpHigh - bpLowVal) * (concentration - bpLowVal) + iaqiLowVal ); } } return 500; } }

这段代码的关键是“双数组同游标”的思路：浓度落在哪个区间，就取该区间两端做线性插值。Math.round保证结果四舍五入成整数。PM2.5 的浓度分级表来自 HJ 633-2012 标准，但不同污染物（PM10、SO2、NO2、CO、O3）的BP数组并不相同，实际开发时要把每个污染物的分段表都定义出来，放进一个Map<String, int[]>，而不是像示例这样只写死 PM2.5 一组。AQI 最终值取各 IAQI 最大值，同时记录“首要污染物”，这样才能在页面上展示“当前首要污染物为 PM2.5”这类信息。

3.3 管理端页面：不用前端框架也能做出像样的图表展示

这类管理系统的前端部分通常不用 Vue 或 React，JSP加原生Bootstrap是主流。图表展示最常见的做法是引入 ECharts 的 CDN 文件，在页面里通过 AJAX 请求后端接口，拿到 JSON 数据后渲染折线图。

$.ajax({ url: '/api/aqi/trend', data: { siteId: 1, days: 7 }, dataType: 'json', success: function (res) { var chart = echarts.init(document.getElementById('aqiChart')); chart.setOption({ xAxis: { type: 'category', data: res.dates }, yAxis: { type: 'value', name: 'AQI' }, series: [{ type: 'line', data: res.aqiValues, smooth: true }] }); } });

后端接口返回的 JSON 结构直接决定前端代码的简洁程度。我一般会设计成{dates: ["2025-01-01", "..."], aqiValues: [55, 78, ...]}这种扁平结构，而不是返回一堆实体对象让前端自己取字段。对应的 SQL 是典型的按天分组取平均浓度：

SELECT DATE_FORMAT(monitor_time, '%Y-%m-%d') AS date, AVG(concentration) AS avg_conc FROM t_air_quality WHERE site_id = #{siteId} AND pollutant_code = 'PM25' AND monitor_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE_FORMAT(monitor_time, '%Y-%m-%d') ORDER BY date;

4. 源码包里的文档该写什么：从运行部署到答辩演示一条线

4.1 一份能过关的文档需要包含的五个部分

“带文档”是整个标题里的交付重心。一份合格的课设级系统文档，不是把代码注释复制一遍，而是要让一个从没看过源码的人，在 30 分钟内能把它跑起来，并能讲清楚设计决策。我推荐的文档结构长这样：

docs/ ├── 01_需求分析.md ├── 02_数据库设计.md # 含ER图、表结构说明 ├── 03_详细设计.md # 核心流程时序、接口定义 ├── 04_运行部署.md # 环境版本、数据库初始化脚本说明、启动步骤 ├── 05_测试用例.md # 功能测试与数据验证样例 └── sql/ ├── schema.sql # 建库建表语句 └── data.sql # 初始站点与演示数据

数据库脚本必须独立成文件，绝不能只写在 WORD 文档里让人手动复制。data.sql里要预先插入 3 个以上站点、一周以上的监测数据，否则答辩现场登录进去看到空页面，整个演示效果直接垮掉。04_运行部署.md是排错第一现场，里面至少应写明 JDK 版本、MySQL 版本、字符集配置方式、应用启动命令和默认端口。

4.2 用文档反查源码：快速定位核心类的三步法

接手一套别人写的源码，最忌讳从头一页页读。我用文档定位代码的顺序是固定的：先看运行部署文档拿到启动类和端口号，再看数据库表名，最后从表名直接跳到 Mapper 层。假设文档里提到t_air_quality表，那么源码里一定可以找AirQuality.java、AirQualityMapper.java、AirQualityMapper.xml三个文件，照此规律能快速画出一条“页面请求 → Controller → Service → Mapper → SQL”完整链路。

如果文档缺失，还有一种反向定位方式：读取Controller类上的@RequestMapping路径，和前端 JS 里的ajaxURL 互相验证。找到 URL 之后把请求参数带到curl命令里调试接口，比满目录翻代码快得多。

4.3 顺带说清这套项目里最容易被问倒的三个点

答辩或面试时，关于这个项目的高频问题集中在三个地方：AQI 的计算过程、数据库为什么这样设计、部署时遇到过什么问题。前两个本文已经覆盖，第三个的答案建议直接在部署文档里写一段“常见坑”，比如 MySQL 5.7 与 8.0 驱动类名不一致导致的ClassNotFoundException。把真实踩坑写进文档，比写十页理论更能证明代码是自己维护的。

5. 验收前一遍跑通：部署检查清单与两个必知参数

把系统交付出去之前，我习惯用一条命令加两个参数完成预检。先检查 JDK 和 Maven 版本：

java -version mvn -version

如果项目是 Spring Boot 构建但无法启动，优先看数据源配置里的时区参数和驱动类：

spring: datasource: url: jdbc:mysql://localhost:3306/air_quality?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver

serverTimezone=Asia/Shanghai必须显式配置，否则 MySQL 8.x 的驱动会因默认时区与系统不一致报The server time zone value异常。driver-class-name在 MySQL 8.x 下是com.mysql.cj.jdbc.Driver，早期 5.x 驱动是com.mysql.jdbc.Driver，如果源码文档里写的是后者而依赖是 8.x，启动必失败。

最后一个验证点是数据库编码。建库语句必须带utf8mb4，否则空气质量站点名称里的中文以及文档中提到的区域名会变成乱码。整个验收流程建议按这个顺序执行：先跑sql/schema.sql和sql/data.sql，再启动应用，然后打开浏览器访问登录页，依次测试站点管理、数据录入、AQI 查询三大功能。任何一个功能失败，就回到对应接口的curl调用上去定位，而不是反复重启应用试运气。

本文还有配套的精品资源，点击获取