简介这是一套面向高校计算机专业学生的Java毕业设计完整项目包主题为基于SpringbootVue的智能家居系统适合需要高分毕设参考或期末大作业实践的同学。项目采用前后端分离架构后端以Springboot实现设备管理、环境数据与用户信息等业务逻辑前端用Vue.js构建交互界面并配套intelligenthomefurnishingsystemdb.sql数据库脚本可支撑远程控制家电、调节光线温度、监控安全状况等场景。压缩包共374个文件约9.42MB涵盖77个java源码、46个vue组件、17个js脚本、14个xml配置、20张jpg与14张png界面截图以及bat启动脚本、yml配置、sql脚本和论文doc文档结构完整便于按模块查阅。资源另附使用说明文档详细讲解环境安装、部署运行与日常维护论文则记录需求分析、功能设计、实现过程与测试结果。目前已有45人学习适合作为毕设参考或完整项目实践帮助提升全栈开发与文档撰写能力。1. 从一份“Java毕业设计”压缩包说起智能家居系统到底该怎么落地很多同学拿到“Java毕业设计-基于SpringbootVue智能家居系统数据库论文使用说明文档.zip”这类资源时第一反应是解压、找 SQL、改数据库密码、跑起来截图交差。但真正做过企业项目的人会反过来看这套东西能不能拆成可复用的能力智能家居系统的核心不是“灯亮了、窗帘开了”而是设备状态怎么建模、指令怎么下发、前后端怎么解耦、数据库怎么设计才能扛住高频状态上报。如果你正在找 Java 毕业设计案例源码或者想用 springboot 项目练手全栈这个标题背后的技术栈其实非常标准Springboot 做 REST 接口和业务编排Vue 做管理端和设备控制面板MySQL 存设备、房间、场景、用户和日志。它适合三类人需要完整项目撑毕业设计的同学、想补全 springboot 配置和 vue 入门实战的开发者、以及想理解物联网管理后台基本骨架的从业者。接下来我不讲空泛概念直接按“能跑、能改、能扩展”的路径拆开讲。2. 智能家居系统的数据模型与接口分层先想清楚设备、房间、场景三张表2.1 设备、房间、场景的实体关系怎么定智能家居系统最容易翻车的地方不是代码而是数据模型。很多毕设项目把设备直接挂到用户下面结果做场景联动时发现“客厅的灯”和“卧室的灯”没法批量控制。常见做法是三层用户 - 房间 - 设备场景作为独立维度关联多个设备。设备表里必须有的字段包括设备编号、设备类型灯、插座、传感器、窗帘、在线状态、当前属性值JSON 或独立字段、所属房间 ID、创建时间。房间表简单房间名、用户 ID、排序。场景表存场景名和触发条件场景与设备是多对多所以需要一张 scene_device 关联表里面存设备 ID、目标状态、延时秒数。下面是一个最小可用的 MySQL 建表语句直接对应 springboot 项目里 entity 层的设计-- 房间表一个用户可以有多个房间 CREATE TABLE room ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, name VARCHAR(64) NOT NULL, sort_order INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 设备表核心表device_type 决定前端渲染什么控件 CREATE TABLE device ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_id BIGINT NOT NULL, device_no VARCHAR(64) UNIQUE NOT NULL, device_type VARCHAR(32) NOT NULL, -- LIGHT / SOCKET / SENSOR / CURTAIN device_name VARCHAR(64) NOT NULL, online_status TINYINT DEFAULT 0, -- 0离线 1在线 current_value VARCHAR(255), -- 存 JSON如 {power:on,brightness:80} update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_room (room_id) ); -- 场景表与关联表场景触发时批量下发指令 CREATE TABLE scene ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, scene_name VARCHAR(64) NOT NULL, trigger_type VARCHAR(32) DEFAULT MANUAL ); CREATE TABLE scene_device ( id BIGINT PRIMARY KEY AUTO_INCREMENT, scene_id BIGINT NOT NULL, device_id BIGINT NOT NULL, target_value VARCHAR(255), delay_seconds INT DEFAULT 0 );逻辑说明device 表的 current_value 用 JSON 字符串存好处是不同设备类型字段不同也不用频繁改表坏处是不能直接 SQL 查询具体属性所以如果要做“所有亮度大于 50 的灯”得在应用层过滤。参数上device_no 建议用 MAC 或序列号不要用自增 ID 当设备编号否则设备离线重连后会乱。online_status 用定时心跳更新不要每次查询都去 ping 设备否则接口响应会被拖死。2.2 Springboot 接口分层Controller 只做参数校验Service 做指令编排很多 springboot 项目把业务逻辑全写在 Controller 里后面加一个“场景执行”功能就要改十几个接口。正确分层是Controller 接收前端请求只做参数格式校验和权限判断Service 负责设备状态查询、指令组装、场景批量执行Mapper 只做单表 CRUD。下面是一个设备控制接口的典型写法RestController RequestMapping(/api/device) public class DeviceController { Autowired private DeviceService deviceService; // 单设备控制前端传设备ID和目标状态 PostMapping(/control) public Result control(RequestBody Valid DeviceControlDTO dto) { // 权限校验当前用户是否拥有该设备 deviceService.checkOwner(dto.getDeviceId(), UserContext.getUserId()); deviceService.sendCommand(dto.getDeviceId(), dto.getValue()); return Result.success(); } // 场景执行一次请求触发多个设备 PostMapping(/scene/{sceneId}/execute) public Result executeScene(PathVariable Long sceneId) { deviceService.executeScene(sceneId, UserContext.getUserId()); return Result.success(); } }逻辑说明checkOwner 不能省否则改一个 deviceId 就能控制别人家的设备这是毕设答辩最容易被问到的安全点。sendCommand 里不要直接返回“成功”因为设备离线时指令会丢正确做法是先把指令写入指令日志表状态置为“待下发”再由定时任务或 MQTT 回调更新为“已执行”。参数上DeviceControlDTO 里的 value 建议用 MapString,Object 而不是 String方便前端传亮度、颜色、开关等多个属性。2.3 Vue 前端怎么按设备类型动态渲染控制组件Vue 入门最容易犯的错是给每种设备写一个页面。设备类型是可扩展的今天加一个“温湿度传感器”明天加一个“智能门锁”不可能每次都改路由。常见做法是用动态组件前端维护一个 deviceType 到组件的映射表后端返回设备列表时带上 device_type前端用component :iscomponentMap[device.deviceType]渲染。控制面板里开关类设备用 switch亮度类用 slider传感器只读用文本。这样新增设备类型只需要加一个 Vue 组件并注册到映射表不用动主流程。3. 用 Springboot 把设备指令链路跑通从 REST 到定时任务的最小闭环3.1 设备心跳与在线状态更新别用同步轮询设备在线状态是智能家居系统里最容易被做“假”的地方。很多毕设项目在查询设备列表时顺便去 ping 设备结果设备一多接口就超时。正确做法是设备主动上报心跳设备每隔 30 秒调用一次/api/device/heartbeat后端更新 online_status 和最后心跳时间同时起一个定时任务每分钟把超过 90 秒没心跳的设备置为离线。这样查询接口只读数据库响应稳定。Component public class DeviceHeartbeatTask { Autowired private DeviceMapper deviceMapper; // 每60秒执行一次把超时未心跳的设备置为离线 Scheduled(fixedDelay 60000) public void markOffline() { // 90秒内没有心跳视为离线 Date expireTime new Date(System.currentTimeMillis() - 90_000); deviceMapper.updateOfflineBefore(expireTime); } }逻辑说明fixedDelay 和 fixedRate 的区别要清楚fixedDelay 是上一次执行完再等 60 秒避免任务堆积。参数 90 秒不是随便定的一般取心跳间隔的 3 倍心跳 30 秒就设 90 秒网络抖动时不会误判。updateOfflineBefore 对应的 SQL 是UPDATE device SET online_status0 WHERE update_time #{expireTime} AND online_status1记得加索引在 update_time 上。3.2 指令下发与状态回传用指令日志表兜底设备控制最怕“前端显示已开实际设备没动”。解决方式是加一张 command_log 表每次控制请求先插入一条记录状态为 PENDING设备执行后回调/api/device/command/ack后端把状态改为 SUCCESS 或 FAILED。前端查询设备详情时如果最近一条指令是 PENDING 超过 10 秒就显示“指令超时”。这样用户知道是设备没响应而不是系统骗他。CREATE TABLE command_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, device_id BIGINT NOT NULL, command_value VARCHAR(255), status VARCHAR(16) DEFAULT PENDING, -- PENDING / SUCCESS / FAILED create_time DATETIME DEFAULT CURRENT_TIMESTAMP, ack_time DATETIME, INDEX idx_device_status (device_id, status) );参数说明status 不要用数字用字符串可读性更好排查问题时一眼能看懂。ack_time 在设备回调时写入用于计算指令延迟。如果项目里没有真实设备可以用一个模拟器定时把 PENDING 改成 SUCCESS保证演示流程完整。3.3 场景执行的批量指令与延时处理场景执行不是简单 for 循环调用 sendCommand因为场景里可能有延时比如“回家模式”先开灯5 秒后开空调。常见做法是把 scene_device 里的 delay_seconds 取出来用 ScheduledExecutorService 做延时调度。注意线程池大小要限制否则一个场景几十个设备会把线程打满。Service public class SceneExecuteService { private final ScheduledExecutorService scheduler Executors.newScheduledThreadPool(4); public void executeScene(Long sceneId, Long userId) { ListSceneDevice items sceneDeviceMapper.selectBySceneId(sceneId); for (SceneDevice item : items) { // 按延时时间调度0秒立即执行 scheduler.schedule(() - { deviceService.sendCommand(item.getDeviceId(), item.getTargetValue()); }, item.getDelaySeconds(), TimeUnit.SECONDS); } } }逻辑说明线程池设 4 是经验值毕设环境足够生产环境要按设备量压测调整。schedule 里的异常必须捕获否则一个设备失败会影响整个场景。参数上delay_seconds 建议限制在 0 到 300 之间太长的延时用定时任务表而不是内存调度否则重启就丢了。4. 数据库设计与前端联调那些答辩时容易被追问的细节4.1 MySQL 连接池与 springboot 配置参数怎么调springboot 默认用 HikariCP毕设项目通常不改配置但答辩老师可能会问“连接池满了怎么办”。最小配置如下spring: datasource: url: jdbc:mysql://localhost:3306/smart_home?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password hikari: maximum-pool-size: 10 minimum-idle: 2 connection-timeout: 30000 idle-timeout: 600000参数说明maximum-pool-size 不是越大越好10 个连接对毕设足够设 100 反而会因为数据库最大连接数限制报错。connection-timeout 30 秒是等待连接的超时不是查询超时查询超时要单独配。serverTimezone 必须写否则插入时间会差 8 小时这是血泪经验。4.2 Vue 路由参数与设备详情页的刷新问题Vue 路由参数在设备详情页很常用比如/device/:id。但很多人发现从设备 A 跳到设备 B 时页面不刷新因为组件复用了。解决方式是在watch里监听$route.params.id或者给router-view加:key$route.fullPath。参数上设备 ID 用 path 参数比 query 参数更直观但如果是筛选条件就用 query刷新后还能保留。4.3 前后端联调时跨域和登录态怎么处理本地开发时 Vue 跑在 8080Springboot 跑在 9090跨域是必踩的坑。常见做法是后端加CrossOrigin或者全局配置 CorsFilter但更推荐在 vue.config.js 里配 proxy把/api代理到后端这样前端代码里不用写完整域名。登录态用 JWT前端把 token 存 localStorage每次请求在拦截器里加Authorization头。注意 JWT 过期时间别设太长毕设演示 2 小时足够。5. 避坑与排查智能家居系统从能跑到能演示的 5 个坎5.1 设备状态不同步前端显示已开数据库还是旧值现象点击开关后前端变了刷新页面又变回去。原因前端只改了本地状态没有等后端返回就更新 UI或者后端更新了 device 表但前端查的是缓存。解决控制接口返回最新设备状态前端用返回值覆盖本地如果用了 Redis 缓存更新数据库后要删缓存别只更新缓存。5.2 场景执行一半失败没有事务和失败记录现象场景里 5 个设备执行到第 3 个报错前 2 个动了后 2 个没动用户不知道发生了什么。原因for 循环里没有异常捕获一个失败全中断。解决每个设备指令独立 try-catch失败写入 command_log 并标记 FAILED场景整体返回“部分成功”和失败列表。5.3 数据库时间差 8 小时serverTimezone 没配现象创建时间是凌晨实际是下午。原因JDBC URL 没写 serverTimezoneMySQL 驱动用了默认时区。解决URL 加serverTimezoneAsia/Shanghai同时确认 MySQL 服务器时区。这个坑在答辩演示时特别致命因为日志时间全乱。5.4 Vue 打包后接口 404proxy 只在开发环境生效现象npm run dev正常npm run build后部署到 nginx接口全部 404。原因vue.config.js 里的 proxy 只在开发服务器生效打包后是静态文件没有代理。解决生产环境用 nginx 配location /api/ { proxy_pass http://后端地址; }或者前端代码里用环境变量区分 baseURL。5.5 设备编号重复没有唯一索引导致脏数据现象同一个设备出现两条记录控制一条另一条不动。原因device_no 没有加 UNIQUE 约束插入时没做去重。解决建表时加UNIQUE KEY uk_device_no (device_no)插入用INSERT ... ON DUPLICATE KEY UPDATE避免重复注册。6. 让这套系统从毕设变成能讲清楚的作品一个验证习惯和扩展思路最后一章不讲大道理讲一个我自己的习惯每次改完设备控制逻辑先不急着开前端而是用 curl 直接打接口看 command_log 表里有没有记录、状态有没有从 PENDING 变 SUCCESS。这个习惯帮我省了无数次“前端背锅”的时间。具体命令如下# 先登录拿 token curl -X POST http://localhost:9090/api/auth/login \ -H Content-Type: application/json \ -d {username:admin,password:123456} # 用 token 控制设备观察返回和数据库 curl -X POST http://localhost:9090/api/device/control \ -H Content-Type: application/json \ -H Authorization: Bearer 你的token \ -d {deviceId:1,value:{power:on}}执行后去数据库查SELECT * FROM command_log WHERE device_id1 ORDER BY id DESC LIMIT 1;如果 status 是 PENDING说明设备没回调检查心跳任务和模拟器如果是 SUCCESS说明链路通了。这个验证方法比看前端日志快得多而且答辩时你可以直接展示 command_log 表证明系统有完整的指令追踪能力而不是“点一下灯亮了”的演示。扩展方向上如果你想让这套智能家居系统更有说服力可以加两个小功能一是设备状态历史表每次状态变化插一条记录前端画一个简单的折线图二是场景定时触发用 Springboot 的Scheduled每分钟扫描一次 cron 表达式匹配的场景。这两个功能代码量不大但能让答辩老师看到你有数据沉淀和自动化调度的意识。数据库方面如果设备量继续涨可以把 current_value 拆成独立属性表或者引入 Redis 缓存设备最新状态但毕设阶段没必要过度设计先把 MySQL 的索引和事务用对更重要。我自己踩过最深的坑是设备心跳和指令回传用了同一个接口结果心跳把指令状态覆盖了排查了一晚上才发现是 update_time 被心跳刷新导致离线判断失效。后来把心跳和指令回传拆成两个接口各自更新不同字段问题才消失。希望帮到你。本文还有配套的精品资源点击获取 Java毕业设计智能家居系统：Springboot+Vue全栈实战与避坑指南
简介这是一套面向高校计算机专业学生的Java毕业设计完整项目包主题为基于SpringbootVue的智能家居系统适合需要高分毕设参考或期末大作业实践的同学。项目采用前后端分离架构后端以Springboot实现设备管理、环境数据与用户信息等业务逻辑前端用Vue.js构建交互界面并配套intelligenthomefurnishingsystemdb.sql数据库脚本可支撑远程控制家电、调节光线温度、监控安全状况等场景。压缩包共374个文件约9.42MB涵盖77个java源码、46个vue组件、17个js脚本、14个xml配置、20张jpg与14张png界面截图以及bat启动脚本、yml配置、sql脚本和论文doc文档结构完整便于按模块查阅。资源另附使用说明文档详细讲解环境安装、部署运行与日常维护论文则记录需求分析、功能设计、实现过程与测试结果。目前已有45人学习适合作为毕设参考或完整项目实践帮助提升全栈开发与文档撰写能力。1. 从一份“Java毕业设计”压缩包说起智能家居系统到底该怎么落地很多同学拿到“Java毕业设计-基于SpringbootVue智能家居系统数据库论文使用说明文档.zip”这类资源时第一反应是解压、找 SQL、改数据库密码、跑起来截图交差。但真正做过企业项目的人会反过来看这套东西能不能拆成可复用的能力智能家居系统的核心不是“灯亮了、窗帘开了”而是设备状态怎么建模、指令怎么下发、前后端怎么解耦、数据库怎么设计才能扛住高频状态上报。如果你正在找 Java 毕业设计案例源码或者想用 springboot 项目练手全栈这个标题背后的技术栈其实非常标准Springboot 做 REST 接口和业务编排Vue 做管理端和设备控制面板MySQL 存设备、房间、场景、用户和日志。它适合三类人需要完整项目撑毕业设计的同学、想补全 springboot 配置和 vue 入门实战的开发者、以及想理解物联网管理后台基本骨架的从业者。接下来我不讲空泛概念直接按“能跑、能改、能扩展”的路径拆开讲。2. 智能家居系统的数据模型与接口分层先想清楚设备、房间、场景三张表2.1 设备、房间、场景的实体关系怎么定智能家居系统最容易翻车的地方不是代码而是数据模型。很多毕设项目把设备直接挂到用户下面结果做场景联动时发现“客厅的灯”和“卧室的灯”没法批量控制。常见做法是三层用户 - 房间 - 设备场景作为独立维度关联多个设备。设备表里必须有的字段包括设备编号、设备类型灯、插座、传感器、窗帘、在线状态、当前属性值JSON 或独立字段、所属房间 ID、创建时间。房间表简单房间名、用户 ID、排序。场景表存场景名和触发条件场景与设备是多对多所以需要一张 scene_device 关联表里面存设备 ID、目标状态、延时秒数。下面是一个最小可用的 MySQL 建表语句直接对应 springboot 项目里 entity 层的设计-- 房间表一个用户可以有多个房间 CREATE TABLE room ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, name VARCHAR(64) NOT NULL, sort_order INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 设备表核心表device_type 决定前端渲染什么控件 CREATE TABLE device ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_id BIGINT NOT NULL, device_no VARCHAR(64) UNIQUE NOT NULL, device_type VARCHAR(32) NOT NULL, -- LIGHT / SOCKET / SENSOR / CURTAIN device_name VARCHAR(64) NOT NULL, online_status TINYINT DEFAULT 0, -- 0离线 1在线 current_value VARCHAR(255), -- 存 JSON如 {power:on,brightness:80} update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_room (room_id) ); -- 场景表与关联表场景触发时批量下发指令 CREATE TABLE scene ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, scene_name VARCHAR(64) NOT NULL, trigger_type VARCHAR(32) DEFAULT MANUAL ); CREATE TABLE scene_device ( id BIGINT PRIMARY KEY AUTO_INCREMENT, scene_id BIGINT NOT NULL, device_id BIGINT NOT NULL, target_value VARCHAR(255), delay_seconds INT DEFAULT 0 );逻辑说明device 表的 current_value 用 JSON 字符串存好处是不同设备类型字段不同也不用频繁改表坏处是不能直接 SQL 查询具体属性所以如果要做“所有亮度大于 50 的灯”得在应用层过滤。参数上device_no 建议用 MAC 或序列号不要用自增 ID 当设备编号否则设备离线重连后会乱。online_status 用定时心跳更新不要每次查询都去 ping 设备否则接口响应会被拖死。2.2 Springboot 接口分层Controller 只做参数校验Service 做指令编排很多 springboot 项目把业务逻辑全写在 Controller 里后面加一个“场景执行”功能就要改十几个接口。正确分层是Controller 接收前端请求只做参数格式校验和权限判断Service 负责设备状态查询、指令组装、场景批量执行Mapper 只做单表 CRUD。下面是一个设备控制接口的典型写法RestController RequestMapping(/api/device) public class DeviceController { Autowired private DeviceService deviceService; // 单设备控制前端传设备ID和目标状态 PostMapping(/control) public Result control(RequestBody Valid DeviceControlDTO dto) { // 权限校验当前用户是否拥有该设备 deviceService.checkOwner(dto.getDeviceId(), UserContext.getUserId()); deviceService.sendCommand(dto.getDeviceId(), dto.getValue()); return Result.success(); } // 场景执行一次请求触发多个设备 PostMapping(/scene/{sceneId}/execute) public Result executeScene(PathVariable Long sceneId) { deviceService.executeScene(sceneId, UserContext.getUserId()); return Result.success(); } }逻辑说明checkOwner 不能省否则改一个 deviceId 就能控制别人家的设备这是毕设答辩最容易被问到的安全点。sendCommand 里不要直接返回“成功”因为设备离线时指令会丢正确做法是先把指令写入指令日志表状态置为“待下发”再由定时任务或 MQTT 回调更新为“已执行”。参数上DeviceControlDTO 里的 value 建议用 MapString,Object 而不是 String方便前端传亮度、颜色、开关等多个属性。2.3 Vue 前端怎么按设备类型动态渲染控制组件Vue 入门最容易犯的错是给每种设备写一个页面。设备类型是可扩展的今天加一个“温湿度传感器”明天加一个“智能门锁”不可能每次都改路由。常见做法是用动态组件前端维护一个 deviceType 到组件的映射表后端返回设备列表时带上 device_type前端用component :iscomponentMap[device.deviceType]渲染。控制面板里开关类设备用 switch亮度类用 slider传感器只读用文本。这样新增设备类型只需要加一个 Vue 组件并注册到映射表不用动主流程。3. 用 Springboot 把设备指令链路跑通从 REST 到定时任务的最小闭环3.1 设备心跳与在线状态更新别用同步轮询设备在线状态是智能家居系统里最容易被做“假”的地方。很多毕设项目在查询设备列表时顺便去 ping 设备结果设备一多接口就超时。正确做法是设备主动上报心跳设备每隔 30 秒调用一次/api/device/heartbeat后端更新 online_status 和最后心跳时间同时起一个定时任务每分钟把超过 90 秒没心跳的设备置为离线。这样查询接口只读数据库响应稳定。Component public class DeviceHeartbeatTask { Autowired private DeviceMapper deviceMapper; // 每60秒执行一次把超时未心跳的设备置为离线 Scheduled(fixedDelay 60000) public void markOffline() { // 90秒内没有心跳视为离线 Date expireTime new Date(System.currentTimeMillis() - 90_000); deviceMapper.updateOfflineBefore(expireTime); } }逻辑说明fixedDelay 和 fixedRate 的区别要清楚fixedDelay 是上一次执行完再等 60 秒避免任务堆积。参数 90 秒不是随便定的一般取心跳间隔的 3 倍心跳 30 秒就设 90 秒网络抖动时不会误判。updateOfflineBefore 对应的 SQL 是UPDATE device SET online_status0 WHERE update_time #{expireTime} AND online_status1记得加索引在 update_time 上。3.2 指令下发与状态回传用指令日志表兜底设备控制最怕“前端显示已开实际设备没动”。解决方式是加一张 command_log 表每次控制请求先插入一条记录状态为 PENDING设备执行后回调/api/device/command/ack后端把状态改为 SUCCESS 或 FAILED。前端查询设备详情时如果最近一条指令是 PENDING 超过 10 秒就显示“指令超时”。这样用户知道是设备没响应而不是系统骗他。CREATE TABLE command_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, device_id BIGINT NOT NULL, command_value VARCHAR(255), status VARCHAR(16) DEFAULT PENDING, -- PENDING / SUCCESS / FAILED create_time DATETIME DEFAULT CURRENT_TIMESTAMP, ack_time DATETIME, INDEX idx_device_status (device_id, status) );参数说明status 不要用数字用字符串可读性更好排查问题时一眼能看懂。ack_time 在设备回调时写入用于计算指令延迟。如果项目里没有真实设备可以用一个模拟器定时把 PENDING 改成 SUCCESS保证演示流程完整。3.3 场景执行的批量指令与延时处理场景执行不是简单 for 循环调用 sendCommand因为场景里可能有延时比如“回家模式”先开灯5 秒后开空调。常见做法是把 scene_device 里的 delay_seconds 取出来用 ScheduledExecutorService 做延时调度。注意线程池大小要限制否则一个场景几十个设备会把线程打满。Service public class SceneExecuteService { private final ScheduledExecutorService scheduler Executors.newScheduledThreadPool(4); public void executeScene(Long sceneId, Long userId) { ListSceneDevice items sceneDeviceMapper.selectBySceneId(sceneId); for (SceneDevice item : items) { // 按延时时间调度0秒立即执行 scheduler.schedule(() - { deviceService.sendCommand(item.getDeviceId(), item.getTargetValue()); }, item.getDelaySeconds(), TimeUnit.SECONDS); } } }逻辑说明线程池设 4 是经验值毕设环境足够生产环境要按设备量压测调整。schedule 里的异常必须捕获否则一个设备失败会影响整个场景。参数上delay_seconds 建议限制在 0 到 300 之间太长的延时用定时任务表而不是内存调度否则重启就丢了。4. 数据库设计与前端联调那些答辩时容易被追问的细节4.1 MySQL 连接池与 springboot 配置参数怎么调springboot 默认用 HikariCP毕设项目通常不改配置但答辩老师可能会问“连接池满了怎么办”。最小配置如下spring: datasource: url: jdbc:mysql://localhost:3306/smart_home?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password hikari: maximum-pool-size: 10 minimum-idle: 2 connection-timeout: 30000 idle-timeout: 600000参数说明maximum-pool-size 不是越大越好10 个连接对毕设足够设 100 反而会因为数据库最大连接数限制报错。connection-timeout 30 秒是等待连接的超时不是查询超时查询超时要单独配。serverTimezone 必须写否则插入时间会差 8 小时这是血泪经验。4.2 Vue 路由参数与设备详情页的刷新问题Vue 路由参数在设备详情页很常用比如/device/:id。但很多人发现从设备 A 跳到设备 B 时页面不刷新因为组件复用了。解决方式是在watch里监听$route.params.id或者给router-view加:key$route.fullPath。参数上设备 ID 用 path 参数比 query 参数更直观但如果是筛选条件就用 query刷新后还能保留。4.3 前后端联调时跨域和登录态怎么处理本地开发时 Vue 跑在 8080Springboot 跑在 9090跨域是必踩的坑。常见做法是后端加CrossOrigin或者全局配置 CorsFilter但更推荐在 vue.config.js 里配 proxy把/api代理到后端这样前端代码里不用写完整域名。登录态用 JWT前端把 token 存 localStorage每次请求在拦截器里加Authorization头。注意 JWT 过期时间别设太长毕设演示 2 小时足够。5. 避坑与排查智能家居系统从能跑到能演示的 5 个坎5.1 设备状态不同步前端显示已开数据库还是旧值现象点击开关后前端变了刷新页面又变回去。原因前端只改了本地状态没有等后端返回就更新 UI或者后端更新了 device 表但前端查的是缓存。解决控制接口返回最新设备状态前端用返回值覆盖本地如果用了 Redis 缓存更新数据库后要删缓存别只更新缓存。5.2 场景执行一半失败没有事务和失败记录现象场景里 5 个设备执行到第 3 个报错前 2 个动了后 2 个没动用户不知道发生了什么。原因for 循环里没有异常捕获一个失败全中断。解决每个设备指令独立 try-catch失败写入 command_log 并标记 FAILED场景整体返回“部分成功”和失败列表。5.3 数据库时间差 8 小时serverTimezone 没配现象创建时间是凌晨实际是下午。原因JDBC URL 没写 serverTimezoneMySQL 驱动用了默认时区。解决URL 加serverTimezoneAsia/Shanghai同时确认 MySQL 服务器时区。这个坑在答辩演示时特别致命因为日志时间全乱。5.4 Vue 打包后接口 404proxy 只在开发环境生效现象npm run dev正常npm run build后部署到 nginx接口全部 404。原因vue.config.js 里的 proxy 只在开发服务器生效打包后是静态文件没有代理。解决生产环境用 nginx 配location /api/ { proxy_pass http://后端地址; }或者前端代码里用环境变量区分 baseURL。5.5 设备编号重复没有唯一索引导致脏数据现象同一个设备出现两条记录控制一条另一条不动。原因device_no 没有加 UNIQUE 约束插入时没做去重。解决建表时加UNIQUE KEY uk_device_no (device_no)插入用INSERT ... ON DUPLICATE KEY UPDATE避免重复注册。6. 让这套系统从毕设变成能讲清楚的作品一个验证习惯和扩展思路最后一章不讲大道理讲一个我自己的习惯每次改完设备控制逻辑先不急着开前端而是用 curl 直接打接口看 command_log 表里有没有记录、状态有没有从 PENDING 变 SUCCESS。这个习惯帮我省了无数次“前端背锅”的时间。具体命令如下# 先登录拿 token curl -X POST http://localhost:9090/api/auth/login \ -H Content-Type: application/json \ -d {username:admin,password:123456} # 用 token 控制设备观察返回和数据库 curl -X POST http://localhost:9090/api/device/control \ -H Content-Type: application/json \ -H Authorization: Bearer 你的token \ -d {deviceId:1,value:{power:on}}执行后去数据库查SELECT * FROM command_log WHERE device_id1 ORDER BY id DESC LIMIT 1;如果 status 是 PENDING说明设备没回调检查心跳任务和模拟器如果是 SUCCESS说明链路通了。这个验证方法比看前端日志快得多而且答辩时你可以直接展示 command_log 表证明系统有完整的指令追踪能力而不是“点一下灯亮了”的演示。扩展方向上如果你想让这套智能家居系统更有说服力可以加两个小功能一是设备状态历史表每次状态变化插一条记录前端画一个简单的折线图二是场景定时触发用 Springboot 的Scheduled每分钟扫描一次 cron 表达式匹配的场景。这两个功能代码量不大但能让答辩老师看到你有数据沉淀和自动化调度的意识。数据库方面如果设备量继续涨可以把 current_value 拆成独立属性表或者引入 Redis 缓存设备最新状态但毕设阶段没必要过度设计先把 MySQL 的索引和事务用对更重要。我自己踩过最深的坑是设备心跳和指令回传用了同一个接口结果心跳把指令状态覆盖了排查了一晚上才发现是 update_time 被心跳刷新导致离线判断失效。后来把心跳和指令回传拆成两个接口各自更新不同字段问题才消失。希望帮到你。本文还有配套的精品资源点击获取