Spring Boot智能家居系统实战：从设备接入到场景联动

简介这是一套面向Java初学者与全栈开发学习者的基于SpringBoot的智能家居管理系统完整源码适用于课程设计、毕业设计及Web全栈项目实践。资源涵盖前后端一体化实现后端采用SpringBootMyBatisPlusMySQL 5.7前端基于VueElementUIAjax完整支撑用户管理、设备控制、多媒体素材图片/视频上传展示等核心功能。压缩包共368个文件含77个Java业务逻辑类、46个Vue组件页、161个SVG图标资源、18个JPG/PNG素材及配套SQL脚本、配置文件yml/xml、构建脚本bat和文档docx总大小15.22MB结构清晰、模块分明便于按层理解MVC架构与B/S系统集成。目前已有695人学习下载附带详细目录文档与必读说明可直接导入IDEA/Eclipse运行是掌握SpringBoot企业级开发与Vue前后端分离实战的优质教学参考项目。1. 项目概述与整体设计思路1.1 为什么做这个智能家居系统做这个基于 Spring Boot 的智能家居管理系统起初是因为自己家里买了不少智能设备——灯光、插座、传感器、摄像头品牌各异各自有各自的 App用起来真的是一团乱麻。手机里装了五六个控制软件想关个灯得找到对应 App家里老人更是完全搞不定。那时候就萌生了一个念头能不能自己动手写一个统一的管理系统把不同品牌的设备全部接入进来在一个界面上完成所有操作正好那段时间在深入学 Spring Boot就决定用 Java 技术栈来做这件事。市面上开源的智能家居平台不少比如 Home Assistant、OpenHAB但它们大多是 Python 或专门语言写的深度定制要改源码门槛不低。而基于 Spring Boot 的方案对于熟悉 Java 生态的开发者来说维护成本、二次开发友好度、部署便利性都有明显优势。这也是我最终锁定了“Spring Boot Java”作为核心实现方案的根本原因。1.2 技术选型的核心考量先说我最终确定的整体技术栈各位可以参考后端框架Spring Boot 2.7.x MyBatis-Plus数据库MySQL 8.0 Redis 缓存设备接入协议MQTTEMQX 作为 Broker实时通信WebSocket 向前端推送设备状态前端Vue 3 Element Plus权限认证Spring Security JWT任务调度Quartz用于场景联动、定时任务选这套方案有三个逻辑。第一Spring Boot 天然自带自动配置和 starter 体系能大幅减少繁琐的 XML 配置开发效率高。第二Java 生态的稳定性在服务端领域是被反复验证过的智能家居系统需要 7x24 小时长期运行偶尔半夜起来看眼手机后台服务绝对不能挂。第三我作为 Java 开发者后续想加什么功能都能自己掌控这是在选型时最重要的考量。1.3 系统要解决的三个核心问题在动手之前我先把需求拆解成了三大块这也是整个系统的核心目标第一个是设备接入和管理。这里要解决的是把 WiFi 设备、Zigbee 设备等通过不同协议接入系统然后在后台统一管理设备的状态、名称、所在房间和分组。设备接入不是一次性的事要考虑到运行过程中设备掉线、重连、固件升级更新的问题所以稳定的状态维护机制是基础。第二个是场景联动与自动化。场景是智能家居的“灵魂”。比如“回家模式”当门锁打开时自动打开客厅灯、拉开窗帘、开启空气净化器。再比如“离家模式”一键关闭所有灯光、插座同时开启安防摄像头布防。这里的实现核心是一套规则引擎能够监听设备上报的事件再依据预设条件触发执行动作。第三个是数据统计与告警通知。设备的状态变化、温度湿度传感器的读数、环境数据的变化趋势这些信息都要落到数据库里形成可查询的历史记录。同时异常情况要能及时通知用户比如烟雾报警器触发、漏水监测报警、家里温度过低都要第一时间推送到手机。这三个问题相互独立又互相依赖设备管理是基础场景联动是上层应用数据统计是价值增值。整个系统的架构图我心里已经刻得很清晰了链路大概是这样的各种智能设备通过 MQTT 协议接入→ EMQX Broker → Spring Boot 后端MQTT 客户端订阅主题 → 业务处理层设备状态更新、规则匹配、告警判断 → MySQL持久化存储 Redis设备在线状态缓存 → WebSocket 推送前端页面实时刷新 → 用户Web 管理界面 手机端这套链路从设备到用户全部打通响应速度实测在 200ms 以内。2. 核心功能模块与数据库设计2.1 六大核心功能模块拆解整个系统按功能边界可以划分为六个核心模块我逐个说一下设计思路。设备管理模块负责设备的注册、配网、状态上报、在线离线管理。设备在系统里以 Device 实体存在包含设备编号、设备名称、类型灯、插座、空调、传感器等、品牌、所属房间、创建时间、最后在线时间等字段。这里设备的所有权与用户绑定支持一个用户下多个设备也支持一个家庭共享同一批设备。用户与家庭模块支持多用户注册登录用户可以创建家庭Home邀请家庭成员加入同一个家庭空间。家庭成员按角色区分权限比如管理员可以添加删除设备、修改场景普通成员只能控制设备、查看状态。这个设计在真实家庭场景里很实用我家里的账号就同时给爸妈分了一个子账号。场景联动模块用户可以自定义场景场景既支持手动触发也支持自动触发。举个例子“晨起模式”是每天早上 7:00 自动把卧室灯光渐亮至 50%、播放轻音乐手动触发则比如一键点击“观影模式”客厅灯关闭、电视打开、窗帘拉合。告警通知模块当设备上报的数据超出了用户设定阈值时系统会生成告警记录同时通过 WebSocket 推送通知到前端并保留历史告警。目前我实现了弹出页面通知和短信接口预留实际业务场景中还可以接入钉钉、企业微信机器人等。数据分析模块环境传感器的历史数据按小时、天、周粒度聚合生成温湿度变化趋势帮助用户了解家庭环境状态。这个模块用的是 MySQL 的聚合查询在数据量上来之后配合 Redis 缓存做热点数据的加速。系统管理模块包括用户管理、设备分类管理、日志管理、参数配置。系统运行日志和用户操作日志最后都要落库这是排除问题时的关键依据。2.2 数据库设计的核心表结构数据库设计是整个系统最需要想清楚的部分。表关系设计得不好后期扩展简直是灾难。我直接展开讲核心表的设计思路给大家提供可以直接抄的表结构。用户表sys_user字段名类型说明idbigint主键usernamevarchar(50)用户名唯一passwordvarchar(100)密码BCrypt加密存储phonevarchar(20)手机号home_idbigint所属家庭IDrolevarchar(20)角色ADMIN/MEMBERcreate_timedatetime创建时间statustinyint状态正常/禁用密码加密这里必须强调千万别明文存密码用 Spring Security 自带的 BCryptPasswordEncoder 足够安全。我在项目里第一次就是踩了明文存储的坑后来补上了加密改造。设备表iot_device字段名类型说明idbigint主键device_snvarchar(50)设备唯一编号SNdevice_namevarchar(100)设备名称device_typevarchar(30)设备类型LIGHT/SOCKET/SENSORroom_idbigint所属房间IDhome_idbigint所属家庭IDprotocol_typevarchar(20)接入协议类型MQTT/HTTPstatustinyint在线状态0离线/1在线last_online_timedatetime最后在线时间extra_infovarchar(500)扩展信息JSON格式设备表里 extra_info 字段我用来存设备的扩展属性比如灯的色温范围、亮度范围、插座最大功率等用 JSON 字符串存储方便不同设备类型灵活扩展不需要为了每种设备建一张新表。房间表iot_room这个表就简单了字段包含 id、home_id、room_name、sort_order记录家庭下的房间信息。客厅、卧室、厨房、卫生间一个个录进去设备再关联到对应房间。场景表iot_scene字段名类型说明idbigint主键scene_namevarchar(50)场景名称scene_typetinyint触发类型1手动/2定时/3联动rule_jsontext触发规则JSON格式action_jsontext执行动作JSON格式statustinyint启用状态home_idbigint所属家庭IDcreate_bybigint创建人IDrule_json 和 action_json 是两个关键字段。rule_json 存储触发条件比如“温度大于30度”或者“每天早上7点”action_json 存储要执行的设备动作列表比如“打开客厅灯、关闭窗帘、调节空调温度到26度”。这种设计可以满足大多数场景的需求且不需要动态建表。设备日志表iot_device_log这个表记录设备上报的所有原始数据字段有 id、device_id、log_type状态/告警/数据、log_dataJSON格式、create_time。这个表数据量增长很快建议按月分表或者定期归档。实际开发中我发现有一个细节容易被忽略很多智能设备上报数据的频率比较高比如温湿度计每 5 分钟上报一次一台设备一天产生的数据就有 288 条。所以日志表必须要考虑数据清理策略我在项目里用了一个 Spring 定时任务每天凌晨自动清理三个月前的日志数据保持查询性能。2.3 为什么用 JSON 字段存储规则和动作我看到很多人在设计规则引擎时喜欢把条件、动作都拆成规范化的一对多表结构。我不否认那种方式在查询统计上更正规但在智能家居这种场景下过度规范化反而带来麻烦。原因有三个第一场景规则的形态太多样了。有“设备属性大于阈值”的有“定时触发”的有“多个条件同时满足”的还有“两个条件任一满足”的用固定列来定义这些规则几乎不可能覆盖所有情况。第二改动频繁。用户随时可能调整场景里的某个阈值或者动作JSON 结构可以很灵活地支持增删改。第三解析快。直接把 JSON 扔给规则解析器就行不需要去组装多张表的联合查询。用 JSON 存储本质上是用空间换灵活性配合 valid 校验和一些规范约束效果很好。3. Spring Boot 项目搭建与核心实现3.1 项目初始化与目录结构创建项目这里我用的 Spring Initializr直接在 IDEA 里新建 Spring Boot 项目选择 Java 8Spring Boot 2.7.5 版本。为什么不选 Spring Boot 3因为当时是 2022 年底Spring Boot 3.0 刚发布不久很多第三方库的兼容性还没跟上尤其是某些 MQTT 客户端库和 MyBatis 相关组件保守起见用了 2.7.x。如果你现在做新项目可以评估一下 Spring Boot 3 的生态情况但稳定优先原则不会变。项目目录结构我遵循了业界常用的分层架构com.cloudhome.smarthome ├── config // 配置类MQTT、Redis、WebSocket、Quartz等 ├── controller // 控制器层 ├── service // 业务逻辑层 ├── mapper // MyBatis-Plus Mapper接口 ├── entity // 数据库实体 ├── dto // 数据传输对象 ├── mqtt // MQTT客户端处理 ├── job // 定时任务 ├── common // 通用类统一返回、异常处理、常量 └── utils // 工具类Controller 层只负责接收请求、返回结果不写任何业务逻辑真正的业务逻辑全部放在 Service 层。这是我写 Java 项目的一个底线。如果你把业务逻辑堆在 Controller 里等系统大起来以后调试和扩展一定会非常痛苦。3.2 统一返回结果与全局异常处理后端 API 设计里统一返回格式是必须的。我封装了一个 Result 类包含 code、message、data 三个字段public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT error(Integer code, String message) { ResultT result new Result(); result.setCode(code); result.setMessage(message); return result; } }这样前端处理响应时只需要统一判断 code 是否为 200减少了大量重复的前端逻辑。全局异常处理则通过 RestControllerAdvice 实现把业务异常、参数校验异常、系统异常分别处理返回友好的错误信息。作为经验之谈在线上的日志中一定要记录完整的异常堆栈不然线上出了 Bug 想排查都无从下手。3.3 MQTT 接入设备与服务器通信的桥梁设备与服务器的通信是整个系统最核心的技术环节。我选择 MQTT 协议的原因很简单它是轻量级的发布/订阅消息传输协议在物联网场景下是事实标准带宽占用小、支持海量连接、网络不稳定时也能断线重连。服务端用的是 Eclipse Paho Java 客户端连接 EMQX Broker。设备上报数据时发布到特定主题比如dev/{device_sn}/report服务端下发控制指令时设备订阅dev/{device_sn}/command主题。MQTT 配置类的核心代码大致如下Configuration public class MqttConfig { Value(${mqtt.host}) private String host; Value(${mqtt.port}) private int port; Value(${mqtt.clientId}) private String clientId; Value(${mqtt.username}) private String username; Value(${mqtt.password}) private String password; Bean public MqttClient mqttClient() throws MqttException { MemoryPersistence persistence new MemoryPersistence(); MqttClient client new MqttClient(tcp:// host : port, clientId, persistence); MqttConnectOptions options new MqttConnectOptions(); options.setCleanSession(true); options.setAutomaticReconnect(true); options.setConnectionTimeout(10); options.setKeepAliveInterval(30); options.setUserName(username); options.setPassword(password.toCharArray()); client.setCallback(new MqttMessageHandler()); client.connect(options); return client; } }需要注意几个关键配置setAutomaticReconnect(true)是必须的否则 EMQX 重启或者网络抖动后客户端不会自动重新连接整个系统就会“假死”。setKeepAliveInterval(30)表示 30 秒发一次心跳用来维持连接防止长时间无消息被对方断开。还有clientId必须全局唯一同一个 clientId 连接同一个 Broker 时后者会把前者踢下线。3.4 WebSocket 实现设备状态实时推送设备上报数据后服务端要第一时间把最新状态推送到浏览器端。HTTP 协议是单向的服务端没法主动给客户端发消息这里就必须用 WebSocket。我用的方案是 Spring Boot 原生提供的 WebSocket 支持通过ServerEndpoint注解实现前端连接后服务端维护一个 session 列表有状态变化时批量推送。核心类大概长这样Component ServerEndpoint(/ws/device) Slf4j public class DeviceWebSocketServer { private static ConcurrentHashMapString, Session sessionMap new ConcurrentHashMap(); OnOpen public void onOpen(Session session) { sessionMap.put(session.getId(), session); log.info(WebSocket连接建立: {}, session.getId()); } OnClose public void onClose(Session session) { sessionMap.remove(session.getId()); log.info(WebSocket连接关闭: {}, session.getId()); } OnError public void onError(Session session, Throwable error) { sessionMap.remove(session.getId()); log.error(WebSocket连接异常: {}, error.getMessage()); } public static void sendMessageToAll(String message) { for (Session session : sessionMap.values()) { try { synchronized (session) { session.getBasicRemote().sendText(message); } } catch (IOException e) { log.error(WebSocket发送消息失败: {}, e.getMessage()); } } } }使用并发安全的 ConcurrentHashMap 管理 session避免多线程并发访问时出现问题。在实际运行中流量大的时候多线程同时推送容易触发ConcurrentModificationException或者 session 超时所以发送时加了 synchronized 锁保证 sendText 的线程安全。3.5 场景联动规则引擎实现场景联动是整个系统的亮点也是最考验设计能力的模块。我的实现思路是定时任务扫描 事件触发 双通道。定时扫描通道通过 Quartz 每 30 秒执行一次场景检查任务把所有启用的自动场景捞出来逐个解析 rule_json判断条件是否满足满足就执行对应动作。这个方式实现简单、逻辑清晰缺点是实时性不强最坏 30 秒延迟。对于绝大多数家庭场景来说30 秒的延迟是可以接受的。事件触发通道当 MQTT 收到设备上报消息时立即触发一次场景检查专为“设备状态变化”这类即时性要求高的场景设计。比如烟雾报警器触发就必须秒级响应不能等定时任务扫描。规则 JSON 的典型结构是这样的{ type: and, conditions: [ { type: device, deviceId: 101, property: temperature, operator: , value: 30 }, { type: time, startTime: 08:00, endTime: 22:00 } ] }解析时可以自己写一个简单的递归判断器从左到右依次评估条件。如果条件满足就遍历 action_json 里的动作数组把控制指令通过 MQTT 下发到对应设备。这里我用了一个设计模式的思想——把每种条件类型封装成独立的判断策略类通过一个工厂类根据类型分发后续新增条件类型时只需要加一个策略类不改动核心逻辑。这也是我这次项目里比较满意的一个抽象设计。4. 关键功能实现深入解析4.1 设备配网流程从零开始绑定设备设备配网是智能家居里用户体验的第一关做得好不好直接影响用户对系统的第一印象。我从产品角度把配网流程梳理成了一个闭环第一步用户在前端输入设备 SN 号或者扫描设备上的二维码进入“待配网”状态。第二步设备通过 MQTT 上报上线消息由于此时设备尚未与用户绑定系统在 MQTT 回调中检查设备 SN 是否绑定过用户如果没有绑定就将其标记为“待绑定”。第三步前端轮询后端查询设备绑定状态如果设备上报的 SN 与用户输入的一致就展示给用户确认确认后绑定到当前用户和房间。第四步绑定成功后设备在 WebSocket 推送中变为在线状态。整个过程中最关键的逻辑在于“设备首次上线时的身份识别”。由于设备可能先于用户操作上线、也可能后于用户操作上线所以不能假定时序要用待绑定列表做缓冲。我在 Redis 中维护了一个device_pending_bind:{sn}的 key过期时间设为 5 分钟配网模式下设备上线时自动写入用户在界面上能看到设备“等待绑定”的提示。4.2 设备控制的幂等性与重试机制设备控制是用户操作最频繁的功能如果控制指令丢失或重复下发用户体验会非常差。我来说说这个问题的两个解决思路。一是指令幂等。像开灯/关灯这种开关类指令天然幂等重复下发也没关系但像调节亮度、色温这类设置类指令如果不做保护连续重复下发可能会出现设备响应不及时或状态闪烁。我采用的方案是控制指令下发后在 Redis 里记录指令的唯一 ID设备上报状态时带上这个 ID后端根据 ID 判断指令执行结果。如果 5 秒内没有收到设备的确认上报则触发重试最多重试 3 次。二是前端操作防抖。在前端控制按钮上加防抖逻辑用户连续点击时只发送最后一次请求避免产生大量重复指令和无效的 WebSocket 推送。实测下来这个优化能减少 70% 左右的控制消息流量效果非常明显。4.3 场景联动执行时遇到的动作并发问题这里分享一个我在实践过程中踩得比较深的坑。最开始实现场景联动时动作执行是串行的先执行动作 A等执行完成后再执行动作 B。结果发现如果一个场景里有 5 个动作最后一个动作可能要等好几秒才能执行到位用户体验很糟糕。后来我改成了使用线程池并发执行动作核心代码如下ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(8); executor.setMaxPoolSize(16); executor.setQueueCapacity(100); executor.setThreadNamePrefix(scene-exec-); executor.initialize(); // 遍历动作提交线程池并发执行 for (SceneAction action : actionList) { executor.execute(() - { mqttGateway.sendCommand(action.getDeviceSn(), action.getCommand()); }); }并发执行的效率提升非常明显但同时也带来了一个新问题多个动作同时下发到同一个设备时设备可能会因为处理不过来而出现丢指令的情况。尤其是同一个智能插座同时收到“打开”和“关闭”两条指令时最终状态是不可控的。解决方法是按照设备维度加锁同一个设备的动作串行执行不同设备的动作并发执行。用 ConcurrentHashMap 管理每个设备的锁对象控制力度恰到好处。4.4 实时告警的实现细节告警模块的核心是阈值判断和通知推送。传感器设备上报数据后服务端不仅更新设备状态还会调用告警规则引擎进行比较。如果超出阈值生成一条告警记录同时根据告警级别决定是否立即推送。告警分为三级提示级如温度偏高、警告级如湿度异常、严重级如烟雾报警。前两级在 Web 页面弹出消息通知不打扰用户严重级告警会额外触发短信通知项目里预留了接口对接阿里云短信服务。这里特别说明一个经验教训告警处理必须做防抖也就是同一设备同一类型的告警在短时间窗口内比如 10 分钟只能推送一次避免设备一波动就连续推送几十条信息把用户烦死。这个防抖我用 Redis 的 SETNX 命令实现key 是告警唯一标识过期时间设 10 分钟避免了在分布式环境下的并发问题。5. 项目管理与部署运维实战5.1 开发环境搭建清单如果你也想复现这个项目环境的版本匹配至关重要。这里我给出实测稳定的版本组合组件版本备注JDK1.8稳定可靠兼容性好Maven3.6依赖管理Spring Boot2.7.5核心框架MySQL8.0.x数据库Redis6.x缓存与在线状态存储EMQX4.3.xMQTT BrokerNode.js14.x前端构建提醒一下JDK 和 Spring Boot 版本不匹配是新手最常见的坑之一。Spring Boot 2.7.x 要求 JDK 8 或 11你用 JDK 17 可能编译通过但运行时会遇到一些诡异的兼容性问题所以新手最好严格按照这个组合来。5.2 数据库脚本与初始化数据数据库脚本我放在了项目的sql/目录下包含建表语句和基础数据。其中有一个细节值得关注设备类型字典表。我预先定义了几种常见的设备类型和对应数据模型模板比如 LIGHT 类型有亮度、色温属性SENSOR 类型有温度和湿度属性。设备接入时根据类型从字典表获取默认属性模板保证同一类设备的数据结构是统一的。初始化数据里还包括一个默认的管理员账号方便首次启动后直接登录体验。这里强烈建议正式上线后立刻修改默认密码。5.3 打包部署流程部署这里我用的是最经典的方式Maven 打包成 Jar 文件放到服务器上通过 systemd 管理。系统层面我还加了一个简单的监控脚本每 5 分钟检查一次服务端口发现挂了就自动重启。打包命令mvn clean package -DskipTests生成的smarthome.jar文件部署到/opt/smarthome/目录创建 systemd 服务[Unit] DescriptionSmart Home System Afternetwork.target [Service] Userroot WorkingDirectory/opt/smarthome ExecStart/usr/local/java/bin/java -Xms512m -Xmx1024m -jar /opt/smarthome/smarthome.jar Restartalways RestartSec10 [Install] WantedBymulti-user.target这里日志的落盘也很重要我把 application.yml 里的 logback 配置了按天滚动保留 30 天日志。排查问题时日志是唯一的线索来源别等到真正出问题才发现没留日志。5.4 前端部署与 Nginx 反向代理前端项目构建后我部署在 Nginx 上同时把/api开头的请求反向代理到后端的 8080 端口。Nginx 配置片段如下server { listen 80; server_name your-domain.com; location / { root /opt/smarthome-web; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /ws/ { proxy_pass http://127.0.0.1:8080/ws/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; } }注意 WebSocket 的代理配置必须设置Upgrade和Connection头否则 WebSocket 握手会失败。我刚开始部署时少了这两个配置结果前端页面一直收不到设备状态的实时推送排查了很久才找到是 Nginx 代理问题。5.5 版本迭代与代码管理经验说实话这类个人项目很容易写着写着就乱了。我吃了不少亏之后养成了两个好习惯非常有用。第一每次功能开发前先在 Git 上建一个 feature 分支开发完成且测试通过后再合并到 dev 分支最后发版时再合并到 master 分支并打上 tag。这样既能保证主干代码的稳定出问题时也能快速回滚。第二写提交信息时把改动的内容说清楚不要写 “fix bug”“update” 这类毫无信息量的提交信息。哪怕是个人项目三个月后回来看也需要能知道这个提交改了什么、为什么改。6. 常见问题排查与避坑指南6.1 设备一直显示离线这个问题我调试了好久总结下来原因无外乎四种设备没有正确连接 MQTT Broker设备上报的主题服务端没有订阅服务端的 clientId 冲突设备网络不稳定导致频繁掉线。排查思路从 Log 入手最靠谱。先看 MQTT Broker 的日志确认设备是否成功连接、是否设置了遗嘱消息LWT再看后端日志中是否打印了 MQTT 回调收到的消息内容。如果消息都收到了那问题大概率出在状态更新逻辑可能设备首次上报时没有在设备表创建记录导致状态更新失败。为了处理这种情况我在设备状态更新的代码里加了一个“若不存在则先创建”的逻辑。6.2 场景联动不触发场景联动不触发先检查几个点场景是否启用了status 是否为 1规则 JSON 中的设备 ID 是否还存在设备可能被删除过设备上报的数据格式与规则中的属性名是否一致。我系统里的温度传感器上报的 JSON 是{temperature: 25.6}关键就是属性名要完全一致。还有一个容易被忽略的点时间条件。如果场景配了时间范围而定时任务运行时设备状态满足条件但时间不在范围内就不会触发。调试时要区分“条件不满足”和“执行失败了”。6.3 消息推送丢失WebSocket 消息丢失通常有三个原因前端 WebSocket 连接断开后没有重连机制服务端推送时 session 已经失效同一时间大量消息并发导致部分推送失败。前端的处理是必须在 onclose 回调中实现自动重连可以每 3 秒尝试一次直到重新建立连接。服务端在推送之前要检查 session 是否 openclose 的 session 直接从 map 里移除。至于并发问题我在前面提到的 synchronized 锁就能解决大部分。6.4 内存溢出与性能优化Java 应用跑几天后内存持续增长、最终 OOM这个问题我在项目初期也遇到过。通过 dump 堆内存分析后发现罪魁祸首是 MQTT 回调中创建的设备状态缓存对象没有及时释放导致内存里堆积了大量临时对象。后来我通过以下方式解决限制缓存的大小使用 Caffeine 缓存替代 HashMap设置最大条目数和过期时间设备日志数据批量写入使用 MyBatis-Plus 的批量插入接口而不是单条逐次插入定时任务里查询数据时使用分页查询并限制单次查询的数据量这里给一个建议如果你用的是 Spring Boot 2.7那么引入 Caffeine 缓存后可以很优雅地和 Spring Cache 注解整合不必自己管理缓存生命周期。6.5 常见问题速查表问题现象可能原因解决思路设备一直离线clientId 冲突或网络问题检查 EMQX 日志查看是否被踢下线场景联动失效规则 JSON 中设备ID失效检查设备是否存在WebSocket 连不上Nginx 未配置 Upgrade 头按上文配置 Nginx定时任务不执行Quartz 配置或线程池阻塞查看定时任务日志前端报 CORS 错误跨域问题后端定义 CORS 配置类接口返回 401token 过期或未携带检查前端请求头7. 实测体验与未来扩展思考整套系统从开发到稳定运行我自己实际用了小半年每天正常操作灯光、空调、窗帘回家前手机上点一下“回家模式”客厅灯自动亮起空调自动调到合适的温度出门时点一下“离家模式”家里所有设备断电安防摄像头开始布防。整体的稳定性和响应速度比我预期的要好不少。在真实的家庭环境里用户对智能家居最大的诉求其实是“稳定”而不是“炫酷”。一个智能场景哪怕技术上再炫如果触发不稳定、有时灵有时不灵用户很快就会对这个系统失去信心。所以我的建议是做这类系统时优先保证核心的、高频使用的功能可靠再慢慢增加花哨的玩法。后续我计划扩展的方向有这几个一是接入更多品牌的设备比如米家系列的智能硬件需要研究不同生态的开放接口二是将 AI 能力引入系统利用设备历史数据做更智能的自动化的场景推荐比如根据家庭成员的作息习惯自动生成场景三是把前端从 Web 网页升级成小程序或手机 App方便家庭成员在手机上更便捷地控制设备。如果你也正在做类似的项目想从零搭建一个基于 Spring Boot 的智能家居管理系统我的建议是先把设备接入和状态管理这条主线跑通再逐步叠加场景联动、告警通知、数据分析这些上层能力。不要一上来就追求大而全逐步演进、稳定迭代才是个人项目做得长远的方式。希望这篇内容能给你一些启发少踩一些我踩过的坑。本文还有配套的精品资源点击获取