基于RuoYi和Spring Boot的在线智能IoT管理系统搭建指南

做在线智能 IoT 管理系统最耗时间的往往不是设备接入协议而是后台管理那套“通用功能”用户登录、菜单权限、操作日志、数据字典、部门管理。这些功能每个项目都要重复写一遍写起来又不能直接产生业务价值。如果你正在做物联网设备管理平台或者准备用 Java 技术栈做毕业设计 / 课程设计 / 企业内部设备监控系统本文会给你一条完整的实现路线基于 RuoYi 框架 Spring Boot MySQL配合 Idea 开发和 HTML/CSS 前端页面快速搭出一个能用的在线智能 IoT 管理系统。先说判断RuoYi 这类快速开发平台真正降低的是通用后台功能的开发成本而不是 IoT 业务本身的复杂度。设备接入协议、数据上报链路、告警规则这些核心逻辑依然需要你亲手设计。所以这篇文章会分成两条线推进一条线讲怎么用 RuoYi 把用户、权限、菜单这些底座跑起来另一条线讲怎么把 IoT 设备管理、数据上报、设备告警做成真正可落地的业务模块。两条线合在一起才是一个完整的在线智能 IoT 管理系统。1. 这篇文章真正要解决的问题很多新手拿到 IoT 项目需求时第一反应是先研究 MQTT 协议先写设备端代码先做通信模块。这个顺序其实反了。设备端只解决“数据怎么传上来”的问题而一个完整的管理系统还要解决“数据传上来之后怎么办”。以我接触过的设备管理类项目为例最常见的状态是设备数据已经通过 MQTT 或 HTTP 上报到服务端但后台没有用户体系没有设备台账没有历史数据查询页面告警只能靠人工看日志。这就像家里装了一堆智能传感器却没有一个统一控制面板数据都在但用不起来。RuoYi 出现在这里是为了解决“控制面板”的问题。它自带了一套成熟的后台管理基础功能用户管理、角色管理、菜单管理、部门管理操作日志、登录日志、数据字典代码生成器可以根据数据库表自动生成 CRUD 代码统一的前端页面框架和权限控制而 IoT 业务本身还需要你做四件事设计设备信息表、设备上报数据表、设备告警表开放一个设备数据上报接口接收设备端推上来的数据提供设备管理页面让运维人员看到所有设备的在线状态、基本信息、最新数据设计告警规则当温度、电压等指标超过阈值时产生告警记录这篇文章适合以下几类读者准备用 Java 技术栈做 IoT 管理系统但不知道如何起步的人想做毕设选题“在线智能物联网管理系统”的大学生以及公司内部需要一个轻量级设备管理后台但不想花三个月从零写权限系统的开发人员。读完这篇文章你会跑通这样一条完整链路初始化 RuoYi 项目 → 设计设备相关数据表 → 用代码生成器生成业务 CRUD → 编写设备数据上报接口 → 开发设备管理前端页面 → 用模拟数据验证设备上报和在线状态更新。2. 核心概念RuoYi、Spring Boot、MySQL 在 IoT 系统中的分工在动手之前先把几个概念讲清楚不然代码写完了可能还是不知道每一层在做什么。2.1 RuoYi 到底是什么RuoYi若依是一个基于 Spring Boot Spring Security MyBatis 的快速开发平台。你从官网下载项目后默认就有用户管理、部门管理、菜单权限、登录认证这些功能。它的核心价值不是“多了一个框架要学”而是帮你省掉了业务系统里最通用的那 30% 代码。RuoYi 有两个常见版本单体版本后端 Thymeleaf 模板页面和前后端分离版本RuoYi-Vue。本文以单体版本为例来说明因为项目标题里明确提到了 html/css单体版本的页面能够直接用 Thymeleaf 模板和 HTML 渲染理解起来更直观。前后端分离版本的思路完全一致只是后端输出 JSON前端用 Vue 做页面业务表的 CRUD 设计没有本质区别。有一个容易踩坑的理解误区以为用了 RuoYi 就不用写代码了。实际上不是。RuoYi 提供的是基础底座和代码生成器它可以生成实体类、Mapper、Service、Controller 的标准 CRUD 代码但设备上报接口、告警判断逻辑、在线状态维护这些 IoT 业务逻辑仍然需要自己写。2.2 Spring Boot 在系统里的角色Spring Boot 是这套系统的运行时骨架。它负责把数据库连接、Web 接口、事务管理、日志等组件组合起来让开发人员少写大量 XML 配置。在 IoT 管理系统里Spring Boot 的职责主要是提供 HTTP 接口接收前端页面的请求提供设备数据上报接口接收设备端或模拟器推送的数据协调 Service 层和 Mapper 层完成数据库读写集成 Spring Security由 RuoYi 默认配置完成登录认证和权限控制如果你之前只用 Spring Boot 写过传统 CRUD那 IoT 系统在接口层并没有多出多少复杂性。真正的复杂性在数据模型设计设备和数据是“一对多”的关系每台设备会持续产生大量上报记录这种数据形态和普通的订单表、用户表是不一样的。2.3 MySQL 在 IoT 系统中的使用边界MySQL 作为这套系统的核心存储负责保存三类数据RuoYi 框架自身的管理数据用户、角色、菜单等、业务基础数据设备台账、时序型数据设备上报记录。这里有一个重要判断如果设备数量少、上报频率低比如家庭场景或小型工厂MySQL 完全够用。但如果设备量达到几万台每台设备每十秒上报一条数据MySQL 很快会遇到写入压力和查询瓶颈。更合理的方案是引入时序数据库如 TDengine、InfluxDB或者对 MySQL 做分表归档。本文作为入门方案先用 MySQL 把完整链路跑通到了生产环境再根据数据量做演进。2.4 一个典型 IoT 管理系统的分层架构从整体架构看这套在线智能 IoT 管理系统可以分成四层层级技术选型主要职责设备接入层HTTP / MQTT接收设备上报的数据应用服务层Spring Boot RuoYi业务处理、权限控制、数据存储数据存储层MySQL保存设备信息、上报数据、告警记录Web 展示层HTML / CSS / Thymeleaf设备列表、状态监控、历史数据展示这个架构对初学者最友好的地方在于每一层都可以单独调试。设备接入层先用 Postman 或模拟器测应用服务层直接用浏览器访问接口数据存储层用 MySQL 客户端查询Web 展示层最后对接接口。分层清晰排错也会容易很多。3. 环境准备与前置条件在开始搭建之前先把开发环境准备好。以下版本以常见的稳定组合为例如果你是直接使用 RuoYi 官网最新代码版本号请以你下载的版本为准。3.1 开发工具与运行环境组件建议版本说明JDK1.8 或 17老版本 RuoYi 建议 1.8新版本建议 17IntelliJ IDEA2023 及以上导入 Maven 项目更方便Maven3.6管理项目依赖MySQL5.7 或 8.0建议 8.0性能更好Redis5.0RuoYi 部分配置可能需要实际不强依赖安装顺序建议JDK → MySQL → Maven → IDEA。JDK 安装后需要配置 JAVA_HOME 环境变量。MySQL 安装完成后要记住 root 密码并确保能通过命令行或客户端连接。3.2 获取 RuoYi 项目RuoYi 的下载和使用方式比较简单。你可以从项目官网获取源码也可以通过 Maven 方式引入相关模块。项目是 Maven 多模块结构典型的模块包括ruoyi-admin启动模块包含启动类和 controllerruoyi-framework框架核心包括安全配置、拦截器ruoyi-system系统管理模块用户、角色、菜单等ruoyi-common公共工具类使用 IDEA 导入时直接选择根目录的 pom.xml让它以 Maven 项目方式加载。首次导入会下载大量依赖国内网络环境下建议把 Maven 仓库地址配置为阿里云镜像否则等待时间会很长。3.3 数据库初始化RuoYi 项目自带 SQL 脚本包含了用户表、角色表、菜单表等基础数据。你需要先创建一个新的数据库例如ry_iot然后执行 RuoYi 项目的ry_xxx.sql脚本。执行完成后表示 RuoYi 的基础表已经就绪。有一点要特别提醒RuoYi 的 SQL 脚本里默认带有字符集配置建议统一使用utf8mb4避免设备名称、位置描述等字段出现中文乱码。后面新增 IoT 业务表时也保持这个习惯。4. 核心数据表设计设备、数据、告警在线智能 IoT 管理系统的核心不是页面也不是接口而是数据表设计。表设计一旦定下来后端代码和前端页面基本就是围绕表结构展开的。先明确实体关系一台设备可以有多条上报数据、多条告警记录所以设备表是主表数据表和告警表是子表。4.1 设备信息表 iot_device设备表保存每台设备的静态信息。这里要注意区分“业务状态”和“在线状态”这两个字段status业务状态表示设备是否被停用与是否在线无关。online_status在线状态表示设备当前是否连接到服务器并保持上报。这两个状态在实际项目里经常被混在一起导致后续排错困难。设计时明确区分后面写在线状态更新逻辑时会清晰很多。CREATE TABLE iot_device ( device_id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 设备ID, device_code varchar(64) NOT NULL COMMENT 设备唯一编码, device_name varchar(100) NOT NULL COMMENT 设备名称, device_type varchar(50) DEFAULT NULL COMMENT 设备类型如温湿度传感器、电表, status char(1) DEFAULT 0 COMMENT 业务状态0正常 1停用, online_status char(1) DEFAULT 0 COMMENT 在线状态0离线 1在线, location varchar(200) DEFAULT NULL COMMENT 安装位置, last_report_time datetime DEFAULT NULL COMMENT 最后上报时间, create_by varchar(64) DEFAULT COMMENT 创建者, create_time datetime DEFAULT NULL COMMENT 创建时间, update_by varchar(64) DEFAULT COMMENT 更新者, update_time datetime DEFAULT NULL COMMENT 更新时间, remark varchar(500) DEFAULT NULL COMMENT 备注, PRIMARY KEY (device_id), UNIQUE KEY uk_device_code (device_code) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENTIoT设备信息表;device_code是设备唯一编码在真实项目里一般是设备出厂时烧录的编号或者是平台分配给设备的标识。这里设置了唯一索引上报接口会根据这个编码定位设备。4.2 设备上报数据表 iot_device_data设备上报数据是 IoT 系统里增长最快的表。这类数据有几个特点只插入、不修改、按时间查询。表设计上要特别关注索引否则数据量一大按设备和时间查历史数据会非常慢。CREATE TABLE iot_device_data ( data_id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 数据ID, device_id bigint(20) NOT NULL COMMENT 设备ID, temperature decimal(8,2) DEFAULT NULL COMMENT 温度值, humidity decimal(8,2) DEFAULT NULL COMMENT 湿度值, voltage decimal(8,2) DEFAULT NULL COMMENT 电压值, report_time datetime NOT NULL COMMENT 上报时间, PRIMARY KEY (data_id), KEY idx_device_time (device_id, report_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT设备上报数据表;这里使用idx_device_time复合索引是为了适配最常见的查询场景查看某台设备在一段时间内的历史数据。如果业务需要按设备类型维度的汇总统计可以考虑增加设备类型冗余字段或者定期做聚合表不要在原始数据表上做太复杂的统计查询。4.3 设备告警表 iot_alarm告警表用来记录设备指标超出阈值的情况。实际项目中告警触发逻辑可以在设备端判断也可以在服务端判断。对于智能 IoT 管理系统推荐在服务端统一判断因为这样规则可以动态调整不用每次更新设备固件。CREATE TABLE iot_alarm ( alarm_id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 告警ID, device_id bigint(20) NOT NULL COMMENT 设备ID, alarm_type varchar(50) DEFAULT NULL COMMENT 告警类型如超温、欠压, alarm_content varchar(500) DEFAULT NULL COMMENT 告警内容, status char(1) DEFAULT 0 COMMENT 处理状态0未处理 1已处理, alarm_time datetime DEFAULT NULL COMMENT 告警时间, PRIMARY KEY (alarm_id), KEY idx_alarm_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT设备告警表;告警表和上报数据表本质上是两种类型的记录数据表是设备“说了什么”告警表是系统“发现了什么问题”。在实际开发中上报数据每一条都会插入但只有满足条件的上报才会插入告警记录所以告警表的数据量会小很多。5. 基于 RuoYi 的后端业务代码实现数据表设计完成后开始写后端代码。RuoYi 自带代码生成器但对于 IoT 业务表最稳妥的方式还是先手动写一遍核心链路理解清楚以后再用生成器提高后续效率。5.1 在 RuoYi 项目中添加设备模块的 Maven 依赖如果你的 RuoYi 项目是多模块结构可以在 ruoyi-admin 模块的 pom.xml 中添加快 JSON 解析库用于处理上报接口的 JSON 数据。RuoYi 本身已经集成了 fastjson通常不用额外添加但如果版本较老可以使用 fastjson2dependency groupIdcom.alibaba/groupId artifactIdfastjson2/artifactId version2.0.36/version /dependency实际开发中这个依赖是否添加取决于项目里已有的依赖树。如果代码里用到了 fastjson 的 JSONObject但没有相关依赖就会出现编译报错。建议先检查依赖树再决定是否添加。5.2 配置数据库连接在 ruoyi-admin 模块的 application.yml 中修改数据源配置指向刚创建的ry_iot数据库server: port: 8080 spring: datasource: type: com.alibaba.druid.pool.DruidDataSource driverClassName: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/ry_iot?useUnicodetruecharacterEncodingutf8zeroDateTimeBehaviorconvertToNulluseSSLtrueserverTimezoneGMT%2B8 username: root password: 123456这里最容易出的问题是serverTimezone配置错误。MySQL 8.0 连接时如果 URL 不指定时区JDBC 驱动会报时区错误。另外characterEncodingutf8是避免中文乱码的关键配置不要漏掉。5.3 编写设备实体类在业务模块下新建com.iot.device.domain.IotDevice实体类。RuoYi 的实体类继承BaseEntity可以复用创建时间、更新时间、备注等公共字段package com.iot.device.domain; import com.ruoyi.common.core.domain.BaseEntity; public class IotDevice extends BaseEntity { private Long deviceId; private String deviceCode; private String deviceName; private String deviceType; private String status; private String onlineStatus; private String location; private String lastReportTime; public Long getDeviceId() { return deviceId; } public void setDeviceId(Long deviceId) { this.deviceId deviceId; } public String getDeviceCode() { return deviceCode; } public void setDeviceCode(String deviceCode) { this.deviceCode deviceCode; } // 其他 getter / setter 省略由 IDEA 快捷生成即可 }这里的lastReportTime虽然是数据库的 datetime 类型在实体类中既可以用Date也可以用StringRuoYi 的代码生成器默认会处理类型转换。为了减少前端格式转换的麻烦这里示例使用 String实际项目中建议统一用 Date在返回 JSON 时配置格式化规则。5.4 编写设备数据上报接口设备数据上报是 IoT 系统的关键接口。它要做三件事根据 deviceCode 找到设备。插入一条设备上报数据。更新设备的最后上报时间和在线状态。另外还要判断温度、电压是否超过阈值如果超过则写入告警表方便运维人员处理。package com.iot.device.controller; import java.util.Date; import java.util.List; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.PostMapping; import org.springframework.web.bind.annotation.RequestBody; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; import com.alibaba.fastjson2.JSONObject; import com.iot.device.domain.IotDevice; import com.iot.device.service.IotDeviceService; import com.ruoyi.common.core.controller.BaseController; import com.ruoyi.common.core.domain.AjaxResult; RestController RequestMapping(/iot/device) public class IotDeviceReportController extends BaseController { Autowired private IotDeviceService iotDeviceService; PostMapping(/report) public AjaxResult report(RequestBody JSONObject body) { String deviceCode body.getString(deviceCode); // 1. 根据设备编码查找设备 IotDevice device iotDeviceService.selectIotDeviceByCode(deviceCode); if (device null) { return AjaxResult.error(设备不存在 deviceCode); } // 2. 记录上报数据 double temperature body.getDoubleValue(temperature); double humidity body.getDoubleValue(humidity); double voltage body.getDoubleValue(voltage); iotDeviceService.insertDeviceData(device.getDeviceId(), temperature, humidity, voltage); // 3. 更新设备在线状态和最后上报时间 iotDeviceService.updateOnlineStatus(device.getDeviceId(), new Date()); // 4. 判断阈值并写入告警 if (temperature 60) { iotDeviceService.insertAlarm(device.getDeviceId(), 超温, 当前温度 temperature); } if (voltage 180) { iotDeviceService.insertAlarm(device.getDeviceId(), 欠压, 当前电压 voltage); } return AjaxResult.success(上报成功); } }这里把阈值写死在代码里只是为了演示完整链路。在实际工程项目中阈值应该放到配置中心、数据库或 Redis 中方便运行时动态修改。告警判断逻辑也应该独立成告警服务避免上报接口过于臃肿。5.5 编写 Service 和 Mapper 方法Service 层需要实现几个核心方法按编码查设备、插入数据、更新在线状态、插入告警。以插入上报数据为例Mapper 层的 SQL 是这样写的insert idinsertDeviceData INSERT INTO iot_device_data(device_id, temperature, humidity, voltage, report_time) VALUES(#{deviceId}, #{temperature}, #{humidity}, #{voltage}, #{reportTime}) /insert更新在线状态和最后上报时间update idupdateOnlineStatus UPDATE iot_device SET online_status 1, last_report_time #{reportTime} WHERE device_id #{deviceId} /update这里涉及一个很关键的业务判断什么时候把设备状态置为离线如果设备异常断电它可能不会再上报数据最后一次上报时间是 10 分钟前如何判定它已经离线最常见的做法是增加一个定时任务比如每分钟扫描一次设备表把“最后上报时间早于当前时间 5 分钟”的设备置为离线。RuoYi 自带定时任务框架可以在系统监控里配置一个定时任务调用离线检测的 Service 方法这是一个完整 IoT 系统必须考虑的问题。5.6 设备管理列表接口设备管理页面需要一个分页列表接口。RuoYi 的 BaseController 提供了startPage()方法配合 MyBatis 的分页插件可以很简洁地实现GetMapping(/list) public TableDataInfo list(IotDevice device) { startPage(); ListIotDevice list iotDeviceService.selectIotDeviceList(device); return getDataTable(list); }这个接口返回的是 RuoYi 约定的分页格式前端表格组件可以直接拿到total和rows不需要自己拼接 JSON。6. 前端页面设备管理列表与状态展示RuoYi 单体版本的前端页面使用 Thymeleaf 模板引擎HTML 文件放在resources/templates/iot/device.html目录下。页面本身使用 Layui 或简单 JavaScript 渲染都可以这里给出一个简洁的例子方便你理解页面如何与后端接口交互。!DOCTYPE html html langzh xmlns:thhttp://www.thymeleaf.org head meta charsetUTF-8 titleIoT 设备管理/title link relstylesheet href/static/css/layui.css /head body div classlayui-container h2在线智能 IoT 设备列表/h2 table classlayui-table iddeviceTable thead tr th设备编码/th th设备名称/th th设备类型/th th在线状态/th th最后上报时间/th th安装位置/th /tr /thead tbody iddeviceTbody/tbody /table /div script src/static/js/jquery.min.js/script script $(function() { $.get(/iot/device/list, function(res) { if (res.code 0) { var rows res.rows; var html ; for (var i 0; i rows.length; i) { var row rows[i]; var status row.onlineStatus 1 ? 在线 : 离线; html tr; html td row.deviceCode /td; html td row.deviceName /td; html td row.deviceType /td; html td status /td; html td row.lastReportTime /td; html td (row.location || -) /td; html /tr; } $(#deviceTbody).html(html); } }); }); /script /body /html这里有一个新手经常踩的坑RuoYi 默认情况下所有接口都需要登录后才能访问。前端页面发起$.get(/iot/device/list)时如果当前会话没有登录态请求会被拦截并重定向到登录页返回的数据就不是 JSON。解决办法有两种第一在浏览器里先访问 RuoYi 的登录页登录成功后再打开设备管理页面第二参考 RuoYi 的权限配置给/iot/**的访问接口配置对应的权限标识再在用户管理中为账号分配权限菜单。无论哪种方式都要理解 RuoYi “先过后端权限认证再访问业务接口”的基本逻辑。7. 运行结果与效果验证后端和前端代码完成后进入验证阶段。验证的目标是跑通“模拟设备上报 → 更新设备状态 → 页面看到结果”的完整链路。7.1 启动项目在 IDEA 中启动 ruoyi-admin 模块的启动类控制台出现Started RuoYiApplication时表示后端启动成功。启动过程中如果出现端口被占用可以修改 application.yml 中的server.port。7.2 准备一条测试设备在 iot_device 表中手动插入一台设备INSERT INTO iot_device(device_code, device_name, device_type, status, online_status, location) VALUES(DEV001, 车间温度传感器, 温湿度传感器, 0, 0, 一号车间);这一步非常重要设备表里如果没有这条记录上报接口会直接返回“设备不存在”。7.3 使用 curl 或工具模拟设备上报先用最简单的 curl 命令模拟一次设备上报curl -X POST http://localhost:8080/iot/device/report \ -H Content-Type: application/json \ -d {deviceCode:DEV001,temperature:25.6,humidity:58.2,voltage:220.3}如果返回结果包含msg: 上报成功说明接口逻辑已经走通。此时查询 iot_device 表会看到online_status变为 1last_report_time变成了当前时间。再查 iot_device_data 表会多出一条上报记录。7.4 验证告警触发再执行一次模拟上报把温度改成 80curl -X POST http://localhost:8080/iot/device/report \ -H Content-Type: application/json \ -d {deviceCode:DEV001,temperature:80,humidity:58.2,voltage:220.3}查看 iot_alarm 表应该能看到一条“超温”告警记录。7.5 验证页面展示打开设备管理页面如果页面能正常显示设备列表并且看到 DEV001 的在线状态是“在线”说明后端接口、前端渲染、数据库更新这条链路全部跑通。如果页面出现数据为空优先打开浏览器开发者工具的 Network 面板查看/iot/device/list这个请求返回了什么。如果返回的是 401 或跳转登录页说明权限没有配置好先走登录流程再测试。8. 常见问题与排查思路在基于 RuoYi 开发 IoT 管理系统的过程中以下问题出现频率很高问题现象可能原因排查方式解决方案页面调用接口返回 401未登录或接口没有配置权限打开浏览器 Network 查看请求状态先登录或为接口配置权限标识设备上报接口返回“设备不存在”device_code 不匹配查询 iot_device 表确认编码检查上报 JSON 中的 deviceCode中文乱码数据库连接 URL 缺少 characterEncoding检查 application.yml添加characterEncodingutf8时间字段相差 8 小时JDBC 时区配置不对查询数据库时间与本地时间URL 添加serverTimezoneGMT%2B8启动时报数据源错误MySQL 未启动或密码错误查看完整堆栈日志确认 MySQL 服务和账号密码设备在线状态一直不变缺少离线扫描定时任务观察 last_report_time增加定时任务做超时离线判断这里单独解释一下 401 的问题。RuoYi 自带 Spring Security默认所有接口都受保护。很多人刚接触时在浏览器地址栏输入接口地址被重定向到登录页就以为后端写错了。实际这是正常现象只要登录后携带会话访问即可。另一个容易忽略的问题是分页参数。RuoYi 的startPage()默认读取pageNum和pageSize参数如果你的前端请求没有传这两个参数接口会返回全部数据。虽然功能没错但设备数量多了以后会拖慢接口响应建议在开发阶段就统一使用 RuoYi 的分页组件。9. 最佳实践与工程建议当整个 IoT 管理系统跑通以后不要急着加新功能先考虑下面这些工程层面的建议。它们决定了这个系统能不能从“demo”变成“能用的后台”。9.1 设备编码规范设备编码device_code是设备在系统中的唯一身份证设计时要有全局视角。建议采用分段编码方式例如前 2 位代表设备类型WD 表示温度、DL 表示电力中间 3 位代表区域编码最后几位代表设备序号这样查日志、做报表、定位设备都能节省不少时间。9.2 上报接口要做幂等和校验设备端可能因为网络抖动而重复上报数据上报接口如果每次都直接 insert会导致数据量膨胀。可以设计一个去重字段比如“设备编码 上报时间戳”在插入前先查重。同时接口参数要做合法性校验防止设备异常时上报负数温度或空值污染历史数据。9.3 在线状态不要依赖设备主动断线IoT 设备不具备稳定的“断线通知”能力设备异常断电后可能永远不会告知服务器。所以在线状态必须依靠超时判断维护。建议设计一个定时任务周期扫描在线设备将最后上报时间超过 5 分钟的设备置为离线。在 RuoYi 中可以直接使用系统自带的定时任务功能不需要额外引入 Quartz。9.4 告警规则要可配置不要在代码里写死阈值。阈值应该保存在配置表里通过管理页面维护。比如温度超过多少触发“超温告警”电压低于多少触发“欠压告警”。这样运维人员调整阈值时不需要重新开发和发布服务。这就是在线智能 IoT 系统里“智能”二字的实际含义。9.5 历史数据归档设备上报数据会持续增长建议从一开始就规划清理策略。最简单的方式是保留近三个月的明细数据更早的数据定期迁移到归档表如果业务允许可以用定时任务删除。对于更复杂的统计需求可以按天汇总设备数据的平均值、最大值、最小值需要查询汇总趋势时直接读汇总表。9.6 权限与安全边界设备管理后台虽然内部使用也要注意权限边界。RuoYi 默认提供了角色和菜单权限建议按角色划分数据权限比如普通运维人员只能查看设备列表和告警管理员才能删除设备、调整告警阈值。涉及到生产环境的设备操作指令下发不要直接暴露给前端必须增加二次确认和操作日志记录。9.7 代码生成器的使用时机当你理解了实体、Mapper、Service、Controller 的写法之后后续新加一张业务表就可以使用 RuoYi 的代码生成器从表结构直接生成标准 CRUD 代码。生成后再根据业务手动改造效率会高很多。但第一张表我仍然建议手写一遍因为你只有理解了底层代码结构才能在生成器生成的代码上做定制否则出了问题都不知道从哪查起。10. 总结与后续学习方向到这里一个基于 RuoYi Spring Boot MySQL 的在线智能 IoT 管理系统已经完整跑通了。你掌握了几个关键设计设备和上报数据的一对多关系、在线状态的超时维护思路、上报接口的告警判断逻辑以及 RuoYi 权限体系对业务接口的影响。下一步建议你从两个方向继续深入一是把模拟上报替换成真实设备接入可以了解 MQTT 协议与 EMQX 这类消息中间件让设备通过 MQTT 上报数据服务端订阅并写库二是完善告警通知当前告警只是写进了数据库如果业务需要可以扩展成短信、邮件或企业微信通知这部分和 Spring Boot 的异步任务、消息队列结合得很紧密。如果你是在做毕业设计或课程设计基于这套系统还可以继续扩展大屏数据可视化、设备地图定位、历史曲线报表等功能技术栈不会变核心还是在数据模型和接口设计上想清楚。建议先打开 IDEA把这一套流程跑一遍再回来看本文的设备表设计部分会更有体会。