Spring Boot植物健康管理系统：温湿度光照数据采集与告警实战

做课程设计或毕业设计，选Spring Boot做植物健康管理这套系统的人不少，但能把温湿度、光照这些物联网数据和后台管理串得明明白白的，确实需要点功夫。我前后带过几届学生做类似项目，自己也完整从零搭过一个基于Spring Boot的植物健康温湿度、光照管理系统，源码、数据库、万字文档一整套都配置过，这里把整个设计思路、实现细节和踩坑经验一次性说清楚，给后面要动手的同学当个参考。

这套系统说到底，就是解决三个问题：环境数据怎么采、数据怎么管、异常怎么告警。围绕这个核心，Spring Boot负责后端接口和业务逻辑，数据库存设备和历史数据，前端做可视化展示。整个过程走下来，你会发现课程设计真正考察的不是会用多少框架，而是能不能把数据流跑通、把需求闭环。

1. 项目整体设计与思路拆解

1.1 为什么选Spring Boot作为主框架

先聊一个最扎心的问题：为什么课程设计选Spring Boot而不是SSH或者SSM？答案很简单——省心。

SSH时代要写一堆XML配置，一个applicationContext.xml就能绕晕人。SSM稍微好点，但整合Spring、Spring MVC、MyBatis的过程对新手依然不友好，光是版本兼容就能折腾一整天。Spring Boot的出现把这套繁琐的配置逻辑全部封装掉了，内置Tomcat，启动就是独立应用，写好Controller就能直接跑。对学生来说，这意味着可以把精力从“怎么配框架”转移到“怎么把业务做对”上，这才是课程设计的核心目标。

用Spring Boot还有一个很实际的好处：招聘市场上Java后端岗位基本都在提Spring Boot，你把它作为课程设计的技术栈写在简历上，面试官至少不会觉得你落伍。而且Spring Boot的生态极其成熟，后续想集成定时任务、邮件发送、WebSocket推送这些功能，都有现成starter可以直接引，扩展性完全不用担心。

1.2 系统功能模块与架构设计

植物健康管理系统按角色划分，核心是管理员和普通用户两条线。管理员负责设备管理、用户管理、数据阈值配置；普通用户负责查看自己关注的植物环境数据、接收告警推送。架构上严格按照经典的三层架构来拆分：Controller层处理请求路由，Service层写业务逻辑，Mapper层操作数据库。

前端部分我建议直接用Thymeleaf模板引擎加Bootstrap，因为课程设计不是前端项目，没必要上Vue全家桶。Thymeleaf和Spring Boot天然集成，放在templates目录下就能自动解析，配合Bootstrap写几个响应式页面，数据看板、曲线图、告警列表就都齐了。说实话，答辩的时候老师更关注你的后端逻辑和数据设计，前端能看、能用、不丑就够了。

数据可视化方面，用ECharts做了温湿度和光照强度的历史曲线图，后端通过接口返回JSON数据，前端用Ajax拉取再渲染。这里有个小技巧：ECharts的折线图对时间序列数据特别友好，连续几天的温湿度曲线一眼就能看出植物生长环境是否稳定，这个细节在答辩时很加分。

1.3 数据库设计的核心考量

数据库设计的合理与否，直接决定这个项目的上限。我见过太多课程设计只用一张表硬扛所有功能，结果写到后面需求稍微一扩展，代码就乱成一团。这套系统我拆了五张核心表，分别为用户表、设备表、传感器数据表、告警记录表和阈值配置表。

五张表之间的依赖关系其实很清晰：设备挂在用户下面，每个设备对应一棵或多棵植物；传感器数据表是核心，记录了每个设备上报的温湿度、光照值和采集时间；阈值配置表决定了什么条件下触发告警。这种拆分方式的好处显而易见，数据冗余少、查询效率高，后续想加一个“根据植物种类自动推荐阈值”的功能，只需在设备表加一个植物类型字段即可。

2. 核心业务逻辑与关键技术实现

2.1 用户登录与权限控制

登录模块看似简单，但它是整个系统的门面。我采用的是Spring Boot集成Spring Security来做认证和授权，数据库里的用户表存密码时用了BCrypt加密。很多同学图省事，密码用MD5存，答辩时老师一眼就看出问题，因为MD5加盐其实并没有改变它是单向散列的实质，并不适合直接用来做密码存储。BCrypt的优势在于每次加密结果都不同，破解成本极高，这才是企业级项目该有的态度。

权限控制通过角色来实现，管理员和普通用户拥有不同的接口访问权限。Spring Security配置类里设置好放行路径和拦截规则后，剩下的业务代码根本不用关心权限问题，这就是框架带来的红利。我建议权限控制只管模块级别就行，不需要细到按钮级别，不然代码量翻倍，课程设计的时间根本不够用。

2.2 温湿度、光照数据的采集与处理

数据采集是这套系统的灵魂，但采集方式要区分两种场景。如果你有真实硬件，可以用ESP32或者STM32接温湿度传感器（比如DHT11）和光照传感器（比如BH1750），通过MQTT协议把数据上发到服务器；如果只是纯软件课程设计，没有硬件条件，就直接在数据库中造模拟数据，或者写一个定时任务往数据表里随机插入温湿度和光照值。

我两种方式都验证过。真实硬件采集的数据有噪声，偶尔会出现传感器读数为0或者温度跳变的情况，后端过滤逻辑里面需要做数据清洗，比如连续两次采集值的差值超过20度，就判定为异常数据并丢弃。纯模拟数据反而简单，前端页面配合ECharts的实时刷新，看起来效果一样好看。

数据接收接口的设计要考虑并发场景，因为设备上报数据频率可能很高。我用的方式是每台设备上报数据时走一个统一接口，先插入数据库，再通过异步线程处理阈值判断。为什么用异步？因为阈值判断和告警通知不应该阻塞数据入库，如果一次告警推送耗时2秒，数据采集就会被拖垮。

2.3 阈值告警机制的实现

告警模块的逻辑一句话就能说清楚：读取设备对应的阈值配置，比较实时监测值，超出范围则生成告警记录并通知用户。但里面的细节值得展开。

每个用户的不同植物可能有不同的适宜温湿度范围，所以阈值配置表的设计不能写死固定数值，而是给每个设备配置独立的温度上限、温度下限、湿度上限、湿度下限、光照上限、光照下限。我在页面端做了一个可拖动的阈值调整组件，用户根据植物种类灵活配置。比如多肉植物需要光照充足但湿度偏低，蕨类植物则偏好高湿和散射光，这些都可以通过调整阈值来实现精准管理。

告警通知的实现方式很多，课程设计阶段优先用站内信，也就是往告警记录表插一条数据，用户在页面上能看到未读告警数量。要求高的可以集成邮件推送，Spring Boot集成JavaMailSender很方便，写一个监听器，产生告警后自动发邮件到绑定邮箱。WebSocket实时推送属于加分项，我建议有余力再做，因为答辩时间有限，站内信加邮件已经能完整说明告警闭环。

2.4 数据可视化与统计报表

数据可视化是课程设计展示效果的高地，ECharts在这里是主角。我用ECharts实现了一个综合看板，页面顶部展示当前温湿度和光照强度的实时卡片，中间是两个时间段的折线对比图，底部是各设备的告警统计柱状图。配色上用了绿色系，贴合植物健康管理这个主题，答辩时视觉效果比纯表格强太多。

统计报表模块我做了日报、周报和月报三种维度。日报展示当天每小时的均值，周报展示一周的趋势，月报展示整个月的环境参数分布。实现方式是利用SQL的DATE_FORMAT函数配合GROUP BY进行聚合统计，而后端只需提供三个查询接口，分别接收天数参数即可。前端用时间选择器控制范围，切换时重新请求接口，逻辑非常直观。

3. 从零搭建项目的完整实操流程

3.1 环境准备与项目初始化

工欲善其事，必先利其器。开发环境的版本选择往往决定了后续省事还是折腾，这里把我验证过的比较稳的组合列出来供参考。

环境这块有两个容易踩雷的细节。第一，Spring Boot版本不要盲目追求最新，我用的是Spring Boot 2.7.x系列，这个版本对Spring Security和MyBatis的兼容性都很好。第二，JDK不要用太新的版本，JDK 8和JDK 11完全够用，JDK 17以上反而会遇到一些老库的不兼容。

项目初始化直接用IDEA的Spring Initializr，依赖选择Spring Web、Thymeleaf、Spring Security、MyBatis、MySQL Driver和Lombok。如果是用IntelliJ IDEA Community版，没有自带Spring Initializr，可以去Spring官网的start.spring.io生成压缩包再导入，也不费事。

3.2 数据库建表与初始化数据

先创建数据库plant_db，执行下面的建表SQL。核心的传感器数据表我做了按月分区，但课程设计阶段数据量不大，普通建表即可，不用刻意追求分区。注意设备表和环境数据表之间的外键关系，建议加上索引，否则数据量一上来，按设备查历史数据的SQL会很慢。

sql复制CREATE TABLE user (
    id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '用户ID',
    username VARCHAR(50) NOT NULL UNIQUE COMMENT '用户名',
    password VARCHAR(100) NOT NULL COMMENT '密码(BCrypt加密)',
    role VARCHAR(20) DEFAULT 'USER' COMMENT '角色',
    email VARCHAR(100) COMMENT '邮箱',
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间'
);

CREATE TABLE device (
    id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '设备ID',
    user_id BIGINT NOT NULL COMMENT '所属用户',
    device_name VARCHAR(50) NOT NULL COMMENT '设备名称',
    plant_type VARCHAR(50) COMMENT '植物类型',
    location VARCHAR(100) COMMENT '安装位置',
    status TINYINT DEFAULT 1 COMMENT '状态:1在线,0离线',
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (user_id) REFERENCES user(id)
);

CREATE TABLE sensor_data (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    device_id BIGINT NOT NULL,
    temperature DECIMAL(5,2) COMMENT '温度(℃)',
    humidity DECIMAL(5,2) COMMENT '湿度(%RH)',
    light_intensity DECIMAL(8,2) COMMENT '光照强度(lux)',
    collect_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '采集时间',
    FOREIGN KEY (device_id) REFERENCES device(id),
    INDEX idx_device_time (device_id, collect_time)
);

CREATE TABLE threshold_config (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    device_id BIGINT NOT NULL,
    temp_min DECIMAL(5,2) COMMENT '温度下限',
    temp_max DECIMAL(5,2) COMMENT '温度上限',
    humi_min DECIMAL(5,2) COMMENT '湿度下限',
    humi_max DECIMAL(5,2) COMMENT '湿度上限',
    light_min DECIMAL(8,2) COMMENT '光照下限',
    light_max DECIMAL(8,2) COMMENT '光照上限',
    update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    FOREIGN KEY (device_id) REFERENCES device(id)
);

CREATE TABLE alarm_record (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    device_id BIGINT NOT NULL,
    alarm_type VARCHAR(20) COMMENT '告警类型:TEMP/HUMI/LIGHT',
    alarm_value DECIMAL(8,2) COMMENT '触发值',
    threshold_value DECIMAL(8,2) COMMENT '阈值',
    status TINYINT DEFAULT 0 COMMENT '状态:0未处理,1已处理',
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (device_id) REFERENCES device(id)
);

初始化数据时注意，密码字段不能直接写明文。可以写一个测试类，用BCryptPasswordEncoder生成加密后的密码字符串，再手动INSERT进数据库，登录测试时才能匹配成功。

3.3 后端核心代码实现

后端代码的结构我是按照职责分包的，entity、mapper、service、controller各司其职。比较有代表性的几个核心代码片段来展开说一下。

首先是实时数据上报的Controller接口，设备或者模拟器通过POST请求上报数据，Service层负责清洗入库：

java复制@RestController
@RequestMapping("/api/device")
public class DeviceDataController {
    
    @Autowired
    private DeviceDataService deviceDataService;
    
    @PostMapping("/{deviceId}/report")
    public Result reportData(@PathVariable Long deviceId,
                             @RequestBody SensorDataDTO data) {
        // 参数校验
        if (data.getTemperature() == null || data.getHumidity() == null) {
            return Result.error("温湿度数据不能为空");
        }
        // 调用service处理数据：清洗、入库、阈值判断
        deviceDataService.processData(deviceId, data);
        return Result.success();
    }
}

Service层我重点做了两件事。第一是数据清洗，判断采集值是否在合理物理范围内，比如温度在-20到60摄氏度之间，湿度在0到100之间，光照在0到200000勒克斯之间，超出范围直接丢弃。第二是阈值判断，从Redis缓存中读取该设备的阈值配置，如果没有缓存则查数据库，判断当前值是否越界，越界的话生成告警记录。用Redis做阈值缓存是我后期优化的，减少了大量数据库查询，但这个不是必需项，普通课程设计直接查库也行。

告警处理的异步逻辑我用的是Spring的@Async注解，配合自定义线程池来执行告警邮件发送，避免同步阻塞。这个设计在答辩时可以重点讲一讲，说明你考虑到设备高并发上报时系统的性能瓶颈。

3.4 前端页面与接口对接

前端页面我规划了五个：登录页、数据看板页、设备管理页、历史数据页、告警中心页。Thymeleaf模板放在resources/templates下，静态资源放在resources/static下，目录结构Spring Boot启动时自动识别，不用额外配置。

数据看板页是整个项目的门面担当。顶部用CSS动画做了一个实时时钟，下面排布三块实时数据卡片，通过Ajax轮询接口获取最新传感器数据。这里的轮询间隔我设置的是5秒，太频繁会给数据库造成压力，太慢又失去实时感。

ECharts折线图的原始数据从后端获取JSON，格式大概是这样：

json复制{
  "code": 200,
  "data": {
    "times": ["2024-05-01 00:00", "2024-05-01 01:00"],
    "temperature": [23.5, 24.1],
    "humidity": [65.2, 64.8],
    "light": [1200, 1350]
  }
}

拿到数据后，分别初始化三个ECharts实例，每个实例对应一个div容器，图表自适应宽度。初始化代码我封装成了一个函数，切换时间范围时重新拉数据再调用一次即可。这套写法虽然简单，但项目展示效果绝对拿得出手。

4. 常见问题与排查技巧实录

4.1 高频问题速查表

做项目的过程就是不断填坑的过程，这里把我见过的问题整理成表，方便后来人快速定位。

4.2 几个深坑排查的真实记录

第一个坑是事务不生效。我一开始在Service实现类里的事务方法上直接加了@Transactional，但如果加的是接口方法上，且实现类使用JDK动态代理时，自调用事务会失效。换句话说，方法A调用同类中的方法B，B标注了事务注解，A没有，那B的事务是不生效的。这个问题非常隐蔽，排查方式是在日志中开启SQL输出，观察是否真正开启了事务。

第二个坑是数据上报接口的并发插入卡死。我用默认的HikariCP连接池，最大连接数是10，当模拟设备用多线程并发上报数据时，数据库连接被占满，后面的请求全部排队超时。排查时通过监控连接池状态发现活跃连接一直打满，后来调整了最大连接数并优化了插入逻辑，多条数据合并批量插入，才算解决。

第三个坑是Spring Security导致ECharts接口401。图表页面加载时，Ajax请求接口没有携带认证信息，被Security拦截了。这个问题的根因是前端页面和后端接口是同域，Session应该自动带上，但因为我前端的接口路径和页面路径前缀不同，触发了跨域检查。解决方式是后端增加CORS配置，允许跨域带上凭证，同时前端在Ajax请求中设置withCredentials为true。

4.3 数据异常的排查逻辑

当页面数据异常时，比如温度曲线出现断点或者突变锯齿，我建议按以下顺序排查：先看设备上报的最原始日志，确认传感器本身是否正常；再看后端数据清洗逻辑是否误杀了正常数据；最后看数据库里的记录是否完整。正常情况下，曲线应该是平滑波动的，因为植物生长环境变化是渐进的，出现断崖式跳变大概率是传感器故障或者数据清洗矫正了异常点。

这里有个小模型：如果环境温度在30分钟内跳变了10度以上，物理上几乎不可能，优先怀疑是传感器接触不良或干扰。我在代码里直接增加了这个限制，超过合理变化速率的数据都标记为异常并记录到日志表，而不是直接丢弃。排查时可以精确定位到是哪条数据出了问题。

5. 配套文档与答辩准备

5.1 万字文档的结构安排

课程设计或毕业设计除了代码，文档同样是大头，有的学校要求几千字，有的要求上万字。我帮学生规划的文档结构基本是固定的，而且每个章节应该重点写什么，这里直接给你拆开讲。

第一章绪论，篇幅控制在一千字左右，重点写清楚“为什么要做植物健康管理系统”——城市化进程加快、园艺爱好者增多、传统人工管理效率低。第二章相关技术介绍，把Spring Boot、MyBatis、MySQL、ECharts、传感器技术的基础原理讲清楚，注意不要抄教材原话，用自己的话概括。第三章需求分析，要画出用例图，列清楚功能需求和非功能需求。第四章系统设计，包含系统架构图、数据库ER图、接口设计文档，这一章是重头戏，也是老师重点翻阅的部分。第五章系统实现，每个功能模块配截图和核心代码，每一段代码都要配文字说明。第六章系统测试，写测试用例、测试过程和测试结果。第七章总结和展望。

5.2 答辩常见提问点

答辩时老师问的问题基本集中在这么几个方向：为什么用Spring Boot而不用其他框架、你的数据库为什么这样设计、阈值告警的实时性怎么保证、系统还有什么可以改进的地方。这些问题都能在正文中找到答案，关键是你自己要对项目的每个设计决策都说得出来理由。

有一个高频问题特别需要注意：“如果设备数量增长十倍，你的系统还能扛住吗？”重点回答方向是：数据库表加索引、引入消息队列削峰、定时任务批量处理数据、用缓存减少数据库压力。这些问题不需要你真的实现，但能说出来给老师一种你认真思考过扩展性的印象，分数基本就不低了。

我一贯的做法是让答辩人画一张系统结构图，把“设备上报 → 后端接收 → 数据清洗 → 入库统计 → 阈值判断 → 告警通知”这条链路用流程图串起来，任何提问都能沿着这条链路展开回答，逻辑就非常清晰。

5.3 项目扩展方向的建议

如果学有余力，我还有几个很好的扩展方向推荐。第一，接入真实硬件，用ESP32开发板加DHT11和BH1750传感器实现真实数据采集，项目直接变身物联网应用。第二，加入微信小程序或移动端，用后端Restful API返回统一JSON格式，小程序端做实时监控。第三，加入机器学习算法，通过历史环境数据训练模型，预测植物生长健康状况或自动推荐最优阈值。第四个是更实用向的：加一个补光和加湿的自动控制模块，当光照低于阈值时自动打开补光灯，湿度低于阈值时自动打开加湿器。你把这个控制逻辑写清楚，整个项目的完整度和实用性立刻就提升了一个档次。

我个人在实际操作中的体会是，这套系统最锻炼人的地方不在于某个技术点有多难，而在于完整的项目落地流程——需求分析、数据库设计、后端开发、前端对接、测试部署、文档撰写，每个环节都走一遍，很多课堂上听不懂的概念就自己通了。如果你正准备动手做课程设计，按上面的思路来，少走弯路是一定的。最后再分享一个小经验：源码和数据库文件从一开始就做好备份，每完成一个阶段就压缩存档一次，我见过太多同学因为电脑崩了重写数据库设计文档，那种痛苦真的不想让你经历第二遍。