SpringBoot+Vue智能家居系统毕设实战：从架构到部署解析

毕业设计做智能家居系统，SpringBoot加Vue这套组合该怎么说呢，属于是Java Web方向的“经典套餐”，技术栈完整度够、学习资源多、演示效果也直观，搞懂一套下来，简历上和答辩PPT里都有东西可写。但越是这样“热门”的题目，越容易踩坑——我见过不少同学拿到一个完整项目源码加SQL脚本加接口文档，反而不知道从哪入手，要么对着代码发懵，要么跑起来全是报错，要么改不动、不会扩展。这篇文章就从一个有经验的开发者视角，把这个典型的“SpringBoot+Vue智能家居系统平台”项目从头到尾拆一遍，讲清楚它到底做了什么、每部分代码解决什么问题、SQL脚本和接口文档该怎么用，以及你在跑通和二次开发中最容易卡住的那些细节。

不管你是拿着现成源码准备理解消化，还是打算按这个思路自己动手做一个，这篇文章都能帮你省下不少瞎折腾的时间。我会尽量说人话，把原理和实操混着讲，能直接落地的步骤绝不含糊。

1. 项目整体设计与技术选型背后的真实考虑

先把这个项目到底长什么样讲清楚。智能家居系统的核心诉求就是：用户能通过一个网页或者App，远程查看家里各个设备的状态（灯、空调、窗帘、传感器这类），并且能远程控制它们。背后要支撑这套业务，需要设备接入、状态上报、指令下发、历史数据记录，当然还要有多用户和权限管理。

这套项目选SpringBoot当后端，选Vue当前端，不是随便拍的。从毕设和中小型项目的现实角度，这两个框架生态成熟、资料多、出问题搜索引擎一搜就有答案，而且前后端分离的开发模式本身就是目前企业里最常见的协作方式。SpringBoot负责搞RESTful API、处理业务逻辑、读写MySQL数据库，Vue负责渲染页面、管理用户交互状态、调用后端接口。前端和后端之间通过JSON格式的数据进行通信。

这里有个很多初学者没想明白的问题：为什么智能家居项目还要搞MySQL数据库？设备状态不是实时上报吗，存数据库干嘛？

这里要区分实时状态和历史数据两个概念。你在页面上看到“客厅灯现在是开的”，这属于实时状态，一般放在内存或者通过消息推送直接推给前端；但“客厅灯过去7天每天开关了几次、耗电多少、有没有异常告警”，这就属于历史数据，必须落库。设备本身也有一堆元数据，比如设备名称、所属房间、类型、品牌型号、创建时间，这些不存数据库，重启服务就全丢了。所以MySQL在系统里的定位是“持久化所有结构化数据”，而Redis或者说内存缓存，也可以用来承担实时状态这类短生命周期数据，但纯毕设项目用MySQL加定时任务足够应付。

再聊技术栈细节的分工：

• 后端SpringBoot：负责设备管理、用户管理、房间管理、场景联动、日志统计这类业务模块，暴露统一的RESTful接口，做参数校验和异常处理。
• 前端Vue：负责页面路由、组件渲染、表单交互、图表展示。一般配Element UI或者Ant Design Vue做界面组件库，用ECharts做传感器历史曲线图。
• 数据库：MySQL存储所有实体表；SQL脚本一般包含建库语句、建表语句、初始数据（比如默认管理员账号、示例房间和设备数据）。
• 通信方式：设备端如果做得完整，会走MQTT协议和硬件交互；如果只是毕设演示，经常用WebSocket或者HTTP接口模拟设备状态上报，这是合理简化。

很多人纠结“我到底要不要真的搞硬件”，这个取决于你的时间预算和答辩要求。如果老师要看到“真东西”，那可以配ESP8266或者树莓派模拟，但核心得分点通常在软件设计上，而不是硬件。拿这套项目来说，后端预留了设备接入接口，前端做了完整可视化控制，基础分已经稳了。

2. 数据库设计与SQL脚本的打开方式

拿到项目先别急着运行，先看SQL脚本，这是最快理解项目业务的方式。一个设计得好的智能家居数据库，表不会特别多，但关系一定清晰。

2.1 核心表结构拆解

一般这套项目里你会看到以下这些核心表，我先说清楚每一张表是干什么用的，这样你看脚本时心里有数：

用户表：存放登录账号、密码（加密后的密文）、手机号、邮箱、角色类型（管理员/普通用户）、状态。注意看密码字段是不是BCrypt加密后的字符串，如果明文存储，说明这个项目要么很老，要么不规范，拿来做毕设建议自行改进。

家庭/房间表：用户可以创建家庭，家庭下面有多个房间（客厅、卧室、厨房）。这里的逻辑是“一个用户可以拥有多个家庭，每个家庭包含多个房间”，扩展性比直接在设备表上挂一个房间字段更合理。但很多毕设项目为了省事，直接做成房间表关联用户，也算简化合理。

设备表：核心中的核心。字段一般包括设备唯一标识（device_id）、设备名称、类型（灯/空调/窗帘/传感器）、状态（在线/离线/禁用）、所属房间ID、品牌型号、创建时间。最关键的点在于，设备“具体有哪些控制属性”怎么存储，比如灯有亮度，空调有温度和模式，窗帘有开合百分比。有些项目结合成一个通用表加一个distinct字段存JSON，有些项目搞物模型，采用设备属性表按类型区分。毕设级别的话，通用表加一个JSON字段完全够用，既简单又灵活。

传感器数据记录表：存温湿度、PM2.5、光照度这类传感器周期性上报的数据，字段不外乎设备ID、数值、采集时间。这张表数据量会比较大，SQL脚本里通常只会放几条示例数据，展示一下表结构。

设备控制日志表：记录谁在什么时间通过什么方式控制了什么设备。这张表一是为了审计，二是为了画图统计用户行为，三是答辩时说“我们的系统有完整的操作追溯能力”时拿得出手。

联动规则表（如果有）：支持“天气大于30度自动打开空调”这种自动化场景，字段包括触发条件、动作列表、启停状态。这是项目的加分项，有这张表说明你考虑了智能化而非单纯手动控制。

2.2 导入SQL脚本的正确姿势

跑SQL脚本最常见的坑是字符集问题。智能家居的设备名称可能带中文，如果建表语句写成DEFAULT CHARSET=utf8，插入中文偶尔会报错或出现乱码。正确姿势是用utf8mb4，注意不是utf8，这是很多老项目脚本踩过的坑。你在导入之前，花一秒钟先确认脚本里的字符集设置，免得后面数据全是问号再回来排查。

另外，SQL脚本文件的执行顺序很重要。有些项目把建库、建表、插入初始数据全放在一个文件里，从头到尾执行一遍就行。但有些项目拆成多个文件，比如schema.sql只管结构、data.sql只管数据，你需要先执行建库脚本，再执行表结构脚本，最后导入数据。如果直接对着data.sql执行，大概率会报“Table doesn't exist”，然后误以为项目源码有问题。

提示：导入前最好先看一眼application.yml或者application.properties里的数据库名、用户名、密码配置，很多项目跑不起来不是代码错，而是你导入数据的库名和配置对不上。

2.3 初始数据里藏着什么

好的SQL脚本一定包含初始数据，不然你启动项目后界面上空荡荡一片。你会看到默认的管理员账号（admin/123456这种）、一个示例家庭、三个房间、十来个模拟设备（客厅灯、主卧空调、厨房烟雾传感器），以及几条传感器的历史数据、几条操作日志。这些初始数据放大了看，其实就是在帮你快速把整个界面跑起来做演示，所以不要手贱把初始设备数据全删了，除非你自己要重新造一批。

也就是说，SQL脚本不只是数据结构定义，它还是项目的人设基础。你导入之后登录系统看到的数据，就是这套项目预先设定好的“演示场景”。答辩演示时，你可以指着这些数据说“这是系统初始化时自动创建的模拟家庭环境”，这一步非常自然。

3. 后端SpringBoot实现逻辑与接口设计的核心细节

看完数据库再看代码，顺序不能反。先懂数据模型，再看代码就能对号入座：这个Controller是对应哪张表、那个Service方法是在改什么字段，思路会很清晰。

3.1 后端模块划分与分层结构

典型的SpringBoot工程结构大概是这样的：

com.example.smarthome ├── controller // 控制层，接收请求，返回结果 ├── service // 业务层，核心逻辑 ├── mapper // 数据访问层（MyBatis的Mapper接口） ├── entity // 实体类，对应数据库表 ├── dto // 数据传输对象，接口入参出参 ├── config // 配置类（跨域、拦截器、WebSocket等） ├── common // 通用类（统一返回结果、异常处理、工具类） └── task // 定时任务模块

为什么实体类和DTO要分开？这是初学者特别容易忽略的点。数据库表字段是固定的，但接口入参和响应字段可以不和表字段一一对应。比如前端只想传“设备ID+目标状态”两个字段来控制设备，你没必要把整个设备的实体类全暴露给前端；返回给前端的数据，也可能需要额外拼一个“所属房间名称”，这个是后组装出来的字段，实体类里没有。分层解耦在这里体现得很清楚，如果你发现某个项目Controller层的入参直接用Entity接收，不算错，但分DTO是更职场、更规范的做法。

3.2 统一返回体与全局异常处理，熟人社会的核心

我特别建议你拿到源码先翻common或者core包，找两个类：一个叫Result、R或者ResponseResult之类的统一定义返回结构，另一个是@RestControllerAdvice标注的全局异常处理器。

统一返回体的意义在于：前端每次拿到的数据都有一个固定的壳子，比如{code: 200, message: "success", data: {...}}，前端只需要写一次判断code的逻辑，后面所有接口都能复用。如果每个接口返回的结构都不一样，前端写起来就是灾难，而且出错了前端也不知道该怎么展示错误信息。

全局异常处理的逻辑同样重要。没有它，后端一旦报错就会直接抛出一堆堆栈信息给前端，接口返回的东西既不是JSON也不是正常结构，前端根本没法解析。有了@RestControllerAdvice，NullPointerException、参数校验失败、自定义业务异常都能被统一拦截，然后转成规范的JSON返回。看一个项目写得好不好，这两个类的质量能说明很多问题。

3.3 设备控制链路的设计思路

设备控制是智能家居系统的核心链路，从前端点击按钮到设备真正执行动作，完整流程大致是：

前端点击开关 → 调用后端接口（比如PUT /api/device/{id}/status，请求体带{status: "on"}）→ 后端鉴权（判断这个设备是否属于当前用户）→ 更新数据库中的设备状态 → 通过WebSocket或者MQTT向设备端下发指令 → 设备确认执行后返回结果 → 前端收到成功响应并刷新UI。

这里面最容易被忽略的是鉴权校验。假设你有多个用户，每个用户管理自己的房子，那用户A就不能控制用户B的设备。很多毕设项目的接口没有任何权限判断，只要能调用接口，传一个设备ID就能控制别人家的设备，这在答辩时被老师问一句“安全设计”就会很难受。所以写代码时请务必在Service层判断一下：当前登录用户的ID和设备的归属用户ID是否一致。

设备离线怎么处理？在线设备直接下发指令，离线设备要么拒绝操作并提示“设备不在线”，要么把指令先存下来，等设备上线后补发。后者属于高级逻辑，毕设做到前者就已经及格了。

3.4 接口文档到底怎么用

标题里提到了“接口文档”，这个值得单独说。接口文档就是把所有RESTful接口的URL、请求方式、请求参数、响应结果、状态码整理成一份说明，一般是Markdown格式、Word文档、Postman导出，或者更规范的Swagger自动生成。

拿到接口文档以后，不要从头到尾背诵，而是拿它当“地图”配合源码使用。先看“用户模块”有哪些接口，再去Controller层找对应实现，对照着看逻辑。这样一遍看下来，整个后端的脉络就清楚了。等你自己需要加功能时，比如加一个“定时控制”接口，你就模仿文档里的已有格式写一个新接口，同时也更新文档，保持项目资料的一致性。

接口文档里值得重点看的部分是错误状态码定义。比如400代表参数错误、401代表未登录或Token过期、403代表无权限、404代表资源不存在、500代表服务端异常。前后端约定好这些语义，Debug时会有力得多。如果拿到手的接口文档没写错误码，建议自己补上，这也是毕设文档的加分点。

3.5 登录鉴权：单点问题还是大坑

几乎每个智能家居系统都要做登录，最常见的方案是Spring Security配合JWT。流程不复杂：用户提交用户名密码，后端验证通过后返回一个带签名信息的Token字符串，前端把Token存到LocalStorage里，每次请求在请求头里带上Authorization: Bearer <token>，后端拦截器验证Token合法后，从Token中解析出用户ID和角色。

这个机制的优点是无状态，服务器不保存登录会话，靠的是Token自身的签名有效性和过期时间，水平扩展时特别友好。缺点也有，就是Token一旦签发，到期前无法主动让它失效，所以在注销时一般靠前端丢掉Token来实现“假注销”，严格场景需要做黑名单机制。毕设中用JWT完全够用，但要能把这个逻辑讲清楚，答辩时就会显得你技术功底到位。

4. 前端Vue实现与数据可视化的关键实践

前端部分一般是这样的技术构成：Vue框架，Vue Router做路由，Vuex或者Pinia做全局状态管理，Axios发请求，Element UI或Ant Design Vue做页面组件，ECharts画图表。有些项目用的Vue2，有些已经升级到Vue3了。如果是Vue2加Element UI，老项目味道比较重，胜在稳定。如果原生支持Vue3和Pinia，说明项目比较新。我个人建议，拿到的项目如果还没写“版本号”，先看一眼package.json，有个全局认知。

4.1 页面组织与路由逻辑

一个典型的智能家居前端页面包括这些视图：

• 登录页：账号密码表单 + 登录接口
• 工作台首页/仪表盘：一次性展示家里的设备和环境概览
• 设备控制页：按房间列出设备，支持开关、调节、查看详情
• 场景联动页：配置自动化规则
• 数据分析页：展示传感器历史趋势，常用折线图
• 设备管理页：增删改查设备，管理房间
• 用户管理页：管理员专属，管账号

路由不是简单把页面列出来就完了，关键是路由守卫。没登录的人不能看设备控制页，管理员才能看用户管理页。Vue Router的beforeEach钩子里检查LocalStorage里有没有Token，没有就跑回登录页；再看目标路由的meta里有没有requiresAdmin，有的话还得再解析一下Token里的角色信息。

这段逻辑有一些项目会漏掉，后果是别人拿到你的前端地址，直接改一下URL就能绕过登录页面进入系统内部页面。我在项目检查中一看到这个坑就头疼，毕竟这属于安全性硬伤，不算复杂但必须补上。

4.2 Axios封装：拦截器决定前端体验

前端请求后端接口，不会每个地方都写一遍axios.get(url)完事，而是会先封装一个统一的request.js。核心逻辑就一句话：请求发出前自动携带Token，响应回来后统一处理业务code和HTTP状态码。

推进过程中你会看到，响应体里code是业务的成功失败标记，比如200是成功，401是Token失效。这时候拦截器要做的不是把401直接当成错误抛给页面，而是先跳转登录页、清除本地缓存，再提示用户重新登录。这个体验如果不处理，用户登录态过期后点击任何按钮都没反应，控制台全是报错，不知道发生了什么，体验非常糟糕。

还有一点是请求loading的统一管理或错误提示的组件化封装，让每个页面不用重复写错误弹窗逻辑。这套东西做得好不好直接影响代码可读性，也是面试官爱问的“前端项目工程化”的体现。

4.3 设备控制页面为什么用WebSocket而不是轮询

设备实时控制是智能家居的体验关键所在。方式一是前端每隔一两秒发一次请求，问“客厅灯现在是多少状态”，叫轮询；方式二是前端和服务器之间建立一条持久连接，服务器有状态变化时主动推给前端，叫推送。

WebSocket就是做推送的。后端设备状态一变，WebSocket服务端立刻广播一条消息，前端监听到以后更新UI。好处是实时性高、服务器压力小，因为不需要反复发请求跑重复查询。坏处是逻辑比普通接口多一点，需要处理连接建立、断开重连、心跳保活这些细节。

在很多完整的项目里，设备控制接口和数据推送用的是两套网络通道，控制走HTTP调用REST接口，状态变化走WebSocket推送。前端在WebSocket实例的onmessage回调里根据消息类型更新对应组件状态，这样哪怕其它用户在客厅开了灯，你的页面也能实时看到变化。

如果你拿到的项目没有WebSocket，只有前端定时轮询，也能跑通，但“实时性”这块答辩时讲起来没那么有亮点。

4.4 图表展示是怎么设计和实现的

数据分析页面一般用ECharts画传感器历史曲线。实现思路很直白：前端进入页面时，调用后端的“按时间范围查询传感器数据”接口，拿到一组时间点和数值，然后渲染成折线图。再高级一点的，还会支持切换时间粒度，比如按小时、按天、按周聚合，或者选择多个传感器曲线叠加对比。

做这块时有几个体验细节点要注意：

• X轴时间是设备上报的时间戳，Y轴是数值，但时间戳如果不转成本地可读时间就直接渲染，图上会显示一长串数字，丑且没法看。
• 传感器数据可能有不连续的情况，比如设备离线那两个小时没有数据，如果简单连线会连出一条穿过无数据时间的假曲线，给人错误判断，需要处理断点。
• 为了演示美观，初始数据的日期要尽量集中在最近几天，不然打开图表一条线从几个月前开始，观感不太好。

不过说实话，很多毕设项目只做到“能展示图表”就停了。你要是想拿高分，就继续改善图表的交互性，比如加缩放、加最大值最小值标注、加数据下载功能，复杂度不高但体验升级非常明显。

5. 项目跑通全流程与前后端联调的常见问题

代码看得差不多了，总要动手跑起来。这一节我按自己无数次跑项目踩坑的经验，把完整流程和最容易出问题的环节记录下来。

5.1 从零到一跑通项目的标准流程

第一步，准备基础环境。JDK用1.8还是11甚至17，以项目pom.xml为准；MySQL建议5.7或8.0；Node环境建议14以上（Vue2项目用Node 14或16比较稳，Vue3项目建议Node 16+）。版本这东西一个不对就可能编译失败，先确认再动手能省很多事。

第二步，导入SQL脚本并验证库里的表和数据都齐了。一种办法是用命令行执行，另一种是用MySQL客户端工具（比如Navicat或DataGrip）打开脚本文件直接运行，完成后刷新一下，数一数表数量对不对。

第三步，改后端配置文件。application.yml里主要检查三项：数据库连接地址、数据库账号密码、Redis地址如果有的话。改完启动SpringBoot应用，看到“Started Application in”这种日志就说明启动成功。这一步如果报错，90%的概率是数据库配置不对或者依赖没下全。

第四步，启动前端。在Vue项目根目录执行npm install装依赖，然后npm run serve启动开发服务器。注意npm install可能比较慢，也经常出现版本冲突，建议用npm install --legacy-peer-deps兜底。启动后浏览器访问本地端口，整个系统就能看到登录页了。

第五步，联调确认。登录默认账号，进入设备控制页，点一下灯的开关，看看状态是否变化、数据库里的记录是否更新。再把前端关了重新打开，确认状态持久化是否正确。

5.2 跨域问题为什么不报错反而更麻烦

前后端分离后，前端默认跑在localhost:8080，后端跑在localhost:8081，浏览器访问前端页面后向前端地址发请求会默认触发跨域。解决方式有三种：

1. 后端加@CrossOrigin注解，逐类或逐方法解决；
2. 后端写一个跨域配置类，实现WebMvcConfigurer，配置允许的路径来源和方法；
3. 前端通过Vue的代理（devServer的proxy配置）把/api开头的请求转发到后端的localhost:8081。

第三种方式在开发阶段最常用，因为浏览器看到的是同源请求，不涉及跨域问题。但要注意，这种方式只在开发服务器下生效，一旦前端打包成静态文件部署到Nginx，就没有devServer这个中转层了，必须靠Nginx自身的反向代理配置把API请求转发到后端。如果项目部署后页面白屏或者接口连不上，十有八九是Nginx的proxy_pass没配好。

5.3 打包部署与常见的坑

如果要在答辩时做正式演示，把前端打包成静态文件部署到Nginx，后端打jar包跑在生产端口，这是相对规范的一套流程。

前端打包命令是npm run build，打完后dist目录里是index.html和一堆静态资源。部署时要注意两点：

• 前端路由如果用的history模式，刷新页面会出现404，需要在Nginx配置try_files $uri $uri/ /index.html;。
• 如果接入了WebSocket，Nginx还需要额外配置proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade";。忘记配的话，WebSocket建立不起来，页面设备状态就没办法实时更新。

后端打包用mvn clean package，生成的jar包直接用java -jar xxx.jar运行。需要重点注意的是，打包时不要把开发环境的配置写死，数据库连接、端口这些建议通过--spring.profiles.active=prod的方式区分环境，或者至少在配置文件里写成环境变量占位符，方便部署时按需替换。

6. 代码改造与二次开发实战：从会用到会改

拿到完整项目只是起点，毕设答辩时老师大概率会问“你自己做了什么”，完全不动代码而只是把别人的项目跑一遍，这种项目是拿不出手的。但“改”的前提是你能拆得动它。

6.1 先找到项目里最容易改出彩的几个模块

设备管理模块是最适合练手的。比如现有的设备类型只有灯、空调、窗帘、传感器，你想新加一种设备类型（比如加湿器、扫地机器人），流程大概是：数据库设备表加一行类型定义，后端枚举类加一个类型值，前端设备类型映射里加上对应的图标和控制组件，设备控制接口里补上对应的属性处理逻辑。整套链路走一遍，你会发现项目全流程的代码你都摸过一遍了。

另一个非常适合扩展的模块是场景联动。比如“回家模式”，用户一进门，自动开客厅灯、拉开窗帘、空调调到26度。你可以先在联动规则表里加规则记录，然后在后端加一个规则解析执行的Service，最后在管理页面配置规则UI。这套逻辑做完，项目智能化程度提升一个档次，答辩讲这个比单纯讲CRUD高级得多。

6.2 新增一个接口的完整链路

假设你要加一个“根据房间ID查询所有在线设备”的接口，标准操作顺序是：

1. Mapper层加查询方法，如果你用MyBatis，就是写SQL注解或者XML；
2. Entity或VO包里确保有承载这个查询结果的结构，必要时新建VO类；
3. Service层写业务逻辑，比如判断房间ID是否存在、过滤出在线设备；
4. Controller层新增映射方法，标注注解并调用Service；
5. 手动调用接口测试，用Postman或直接浏览器调试，确认正常；
6. 更新接口文档，补充新增的URL和参数说明。

这个流程走一遍你就会发现，项目扩展的核心不是写代码本身，而是遵守现有项目约定，比如返回值结构、命名方式、异常抛出方式，能让你的代码跟老代码浑然一体。胡乱发挥，风格突变，反而会让整体质量看起来很不专业。

6.3 断点调试：查问题最快的方式

别再用打印日志排查问题了，直接上断点结论快得多。后端用IDEA打断电点，在前端页面上触发一个接口请求，走到Debugger窗口逐步往下跟，看清楚每一步变量的值。这个项目里最典型的场景：设备控制后数据库状态没变，就在Service层更新状态那一步打断点，看看传入的status参数是不是预期值，再继续看sql语句是否真的执行了。

前端掉链子也一样，按F12打开浏览器开发者工具，切到Network面板看请求和响应，一眼就能判断是接口报错还是前端逻辑写错。切到Console面板看一下有没有JavaScript报错，确定到底是请求没发出去、返回数据不对，还是渲染环节出了问题。

7. 实战中高频踩坑记录与排查速查表

这些是我多年看毕设项目过程中，反复遇到的高频问题。把这些问题和排查方式整理成一个速查表，按这个顺序查，大多数问题十分钟内能找出根因。

看到这个表你会发现，大部分问题不涉及源码逻辑本身，而是环境、配置、部署习惯的问题。这恰恰说明项目源码本身给你的工程量是够的，难点全在怎么理解和用好它。

8. 怎样把项目讲到答辩得高分

最后聊一个很多人忽视的环节：项目代码没问题，但答辩时不会讲。这个项目本身亮点不少，但你要抓住几个重点，而不是从头讲到尾。

第一，讲清楚你解决了什么问题，而不是念代码。你可以说：市面很多智能家居Demo只做手动控制，没有考虑多用户权限和设备归属，也没有自动化联动能力。我的系统在这几个方向上做了完整设计。这句话出来，老师第一印象就是你思考过问题，不是只会抄代码。

第二，突出系统的完整链路。从前端页面到后端接口、到MySQL持久化，再到WebSocket实时推送、异常处理和权限校验，完整讲出数据是怎么流动的，比单独背十个接口名管用得多。

第三，准备好回答可能被追问的几种技术问题。比如“为什么用JWT不用Session”，回答“因为前后端分离项目中后端无状态服务天然适合Token，且移动端和网页端共用一套权限机制”；再比如“数据库表为什么这样设计”，回答“设备属性用JSON字段存储是为了应对类型扩展，一个设备表不需要为每一种新设备类型新增列”。这些问题不是额外工作，而是你理解这个项目的自然结果。

第四，如果想让项目再发光，加一点小而精的功能。比如在联动规则表里加一条“当温湿度传感器温度大于30度时，自动打开空调”，实现完整闭环。这个细节不需要特别多代码，但演示效果和答辩素材直接翻倍。

9. 写在最后的个人经验

把这套SpringBoot+Vue智能家居系统完整跑通一遍，你对Java Web全栈开发的认知基本能上一层台阶。源码加SQL脚本加接口文档这套组合，本质上就是一个完整的软件交付物——数据库是地基，后端是业务大脑，前端是用户触达，接口文档是团队协作的契约。你在本科阶段能独立讲清楚这四者如何衔接，这种训练已经超过很多只背面试题的候选人。

我自己在实际跑这种项目的经验是，万事别急，先把SQL脚本看完，再把项目启动起来，接着按一个业务链路（比如“登录到控制客厅灯”）把代码从头到尾读一遍。这套流程走完，你对项目的理解深度会远超那些只跑通页面就觉得自己做完的人。最后再叮嘱一句，一定要自己动手改代码，哪怕只加一个设备类型或一条联动规则，只有亲手改过，这套源码才是真正属于你的东西。祝你在毕设和答辩中都能把这套项目吃透。