企业官网建设流程全解析

1. 项目全貌：这个毕设到底在做什么

做毕设选到这个题目，ssm+vue做前后端分离的物联网数据管理系统，同时接入蓝牙和WiFi两条数据采集链路。很多同学看到“蓝牙+WiFi”第一反应是“这俩是不是重复了”，其实不是。蓝牙负责近距离、低功耗的本地设备接入，比如温湿度传感器、心率模块、串口仪表；WiFi负责把聚合后的数据远程送上服务器。两者结合，正好覆盖了“本地采集—远程传输—服务端存储—前端展示”的完整IoT数据管理闭环。

对毕设而言，这个选题最划算的地方在于：一个题目同时涉及嵌入式、无线通信、后端开发、前端可视化四个方向，论文有得写，程序有得做，演示时也有看头，不会出现“做了个删删改改的增删改查”这种尴尬情况。适合物联网工程、软件工程、电子信息、计算机科学等专业的应届毕业生，尤其是想做前后端分离但又不想只做管理系统的同学。哪怕你之前没怎么碰过硬件，跟着文章思路走，一个月左右把核心链路跑通是完全可以做到的。

2. 技术架构与模块选型

2.1 SSM框架为什么依然能打

SSM是Spring、SpringMVC、MyBatis三件套的缩写。很多同学问：都已经2026年了，怎么还选SSM？这里有个现实逻辑：毕设的目的不是追新，而是用你最能讲清楚的技术，把完整业务闭环做出来。Spring负责Bean管理和事务控制，SpringMVC负责HTTP请求的路由分发，MyBatis负责数据库操作。三者各管一段，职责清晰，出了问题也容易定位。

拿这个项目来说，后端需要干的活无非是：接收蓝牙和WiFi上传的数据、校验设备身份、写入MySQL、提供查询和统计接口、给管理员做登录鉴权。这些需求SSM都能非常自然地承接。MyBatis在写动态SQL时尤其方便，因为传感器数据表有时候会加字段，比如某个设备突然上报了PM2.5数据，你不想改实体类，可以用动态SQL的<if>标签灵活拼接，避免大面积返工。

后端分层建议还是标准的三层结构：Controller接收请求、Service写业务逻辑、Mapper操作数据库。这个项目里我建议在Service层加一个DataHandleService，专门负责对原始上报数据做解析和校验，因为蓝牙和WiFi上报的JSON格式可能不一致，统一在Service层做清洗，Controller保持干净，后面的维护会省很多事。

2.2 Vue前端负责什么

Vue在项目里的定位是数据可视化与交互操作台。虽然题目叫“数据管理系统”，但如果你只做个表格列表，答辩时很难出彩。我的建议是至少实现四个页面：设备管理页、实时数据看板、历史数据查询页、系统管理页。

技术栈用Vue 2还是Vue 3？如果你们学校论文模板里主流还是Vue 2的案例，且你对Element UI比较熟，用Vue 2完全没问题。Vue 3的组合式API写起来更清爽，但如果你赶时间，Vue 2的选项式API反而是最稳妥的，因为网上资料多，遇到问题搜索成本低。

实时数据看板推荐用ECharts做曲线图和仪表盘。物联网数据看趋势比看单点数值更有说服力，比如温湿度变化曲线、设备在线状态统计，这些图表一摆，程序完成度立刻上一个档次。前端通过axios调用后端接口，务必在vue.config.js里配置devServer的proxy代理，否则开发阶段跨域问题会让你怀疑人生。

2.3 硬件选型：HC-05、ESP8266、ESP32怎么选

这题是整个毕设最关键的硬件决策。很多同学上来就纠结到底买哪个，其实只要想清楚你的应用场景就行。

如果你不想折腾，我强烈建议直接选ESP32。理由很简单：它一块芯片同时支持蓝牙和WiFi，你可以在一个程序里既通过蓝牙与手机通信，又通过WiFi把数据推给后端，题目里的“蓝牙和wifi模块数据管理”直接用一块板子就都覆盖了。HC-05虽然便宜，但只支持经典蓝牙，而且需要额外的USB转TTL模块配合调试，两三天踩坑是常态。

如果你是严格按“两个独立模块”来设计的，那就选“HC-05负责蓝牙采集 + ESP8266负责WiFi上报”，两个模块通过串口对接。这种方案的好处是每一部分的技术点更独立，论文里能写的细节更多，坏处是接线和调试工作量翻倍。

3. 核心功能实现与实操链路

3.1 蓝牙数据采集链路怎么搭

蓝牙这条链路的核心是“串口透传”。HC-05或者ESP32的蓝牙串口，本质上就是把收到的字节流原封不动地转发给另一端。你的传感器接在单片机上，单片机把采集到的数据通过串口发给蓝牙模块，蓝牙模块再无线传给接收端（比如手机或者电脑），接收端通过虚拟串口拿到数据。

我用ESP32实操时的代码思路是这样的：蓝牙串口初始化为SerialBT，传感器数据通过SerialBT.print()发送，同时监听手机发来的指令。比如定义几个简单协议：

• GET_TEMP：返回温度值
• GET_HUMI：返回湿度值
• GET_STATUS：返回设备在线状态

这里有个坑，就是SerialBT和默认的Serial是两套串口，很多人改了Serial却忘了改SerialBT的波特率，导致手机虽然连上了蓝牙，但收不到任何数据。我建议统一用115200，并且在初始化后打印一行调试信息，确认蓝牙串口真的启动了。

手机端调试推荐用“蓝牙串口助手”这类App，用来验证链路通不通，但毕设演示时最好还是用我们自己写的Vue页面配合Web Bluetooth API，或者用Electron做一个桌面端，这样整体更完整。如果不想碰Web Bluetooth，最简单的做法是：蓝牙数据先到手机App，App再通过HTTP转发到后端。虽然中间多了个跳板，但技术栈更简单。

3.2 WiFi数据上报链路怎么搭

WiFi链路的核心是HTTP请求。ESP8266或ESP32连上路由器后，通过HTTP POST把JSON数据推送到后端接口。协议格式我建议统一为：

{ "deviceId": "esp32_001", "timestamp": "2026-05-18 12:30:00", "type": "env", "data": { "temperature": 26.5, "humidity": 58.2 } }

后端接口设计为POST /api/data/report，接收上面的JSON，写入数据库。注意设备ID必须做校验，否则任何人都能往你的系统里塞假数据。我见过不少毕设连设备鉴权都没做，答辩时评委一问“如果别人知道你的接口地址，随便造数据怎么办”，直接卡壳。

ESP32端发送数据的核心代码片段：

#include <WiFi.h> #include <HTTPClient.h> const char* ssid = "你的路由器SSID"; const char* password = "你的路由器密码"; void sendData() { HTTPClient http; http.begin("http://你的服务器IP:8080/api/data/report"); http.addHeader("Content-Type", "application/json"); String body = "{\"deviceId\":\"esp32_001\",\"type\":\"env\",\"data\":{\"temperature\":26.5}}"; int code = http.POST(body); http.end(); }

连接WiFi时建议加上自动重连逻辑。我实测下来，路由器重启或者信号波动时，WiFi.status()会变成WL_DISCONNECTED，这时需要WiFi.reconnect()，并在失败后延时几秒重试，否则设备掉线后不会自己回来，整个数据链路上就断了。

另外提醒一句：上报频率别太猛。有些同学为了让数据“看起来多”，让ESP32每秒上报一次，结果把服务器打崩了，数据库里全是重复数据。建议5到10秒上一次，批改老师要的是“系统稳定”，不是“数据爆炸”。

3.3 后端数据接收与存储怎么设计

SSM后端接收蓝牙和WiFi上报的数据，关键是把“上报”和“管理”两套逻辑分开。上报接口不需要登录态，走设备ID校验；管理页面则需要登录后才能访问，否则你的系统就是裸奔的。

数据库设计我直接给出最简可用的方案，四张表就够了：

• device：设备表，存设备ID、名称、类型、在线状态、最后上报时间
• sensor_data：传感器数据表，存设备ID、数据类型、数值、上报时间
• user：用户表，存管理员账号密码
• system_log：操作日志表，存用户登录、删除设备等关键操作

sensor_data表是典型的时间序列表，数据量会持续增长。这里要给device_id和report_time建联合索引，否则数据量到了几万条之后，按设备查历史记录会明显变慢。MyBatis的Mapper里用<where>动态拼接查询条件，让用户既能按设备过滤，又能按时间范围过滤。

接收接口的实现要点是：记录日志。每一个上报请求都写一行系统日志，记录设备ID、上报内容、处理结果。这既是论文里“系统健壮性”的论据，也是排查问题时的重要线索。我就是靠日志定位了一个困扰两天的Bug——某设备端的时间戳格式是yyyy/MM/dd，而数据库要求的是yyyy-MM-dd，解析直接抛异常，日志一眼就看出来了。

3.4 前端看板和后端接口怎么对接

后端接口设计遵循REST风格，前端页面按接口来划分模块。我的接口规划是：

• GET /api/device/list：获取设备列表
• POST /api/device/add：添加设备
• PUT /api/device/update：修改设备信息
• DELETE /api/device/delete/{id}：删除设备
• GET /api/data/realtime/{deviceId}：获取最新一条数据
• GET /api/data/history/{deviceId}：获取历史数据列表
• GET /api/data/stats：获取统计汇总数据
• POST /api/user/login：登录

前端把上述接口封装到src/api目录下，用一个request.js统一管理axios实例。这里强烈建议给axios加请求拦截器和响应拦截器：请求拦截器自动带token，响应拦截器统一处理401跳转登录页和500错误提示。否则每个页面都要写一遍错误处理，代码冗余不说，出bug的概率也高。

数据看板推荐用ECharts的折线图展示历史趋势，用仪表盘展示当前最新值。折线图的数据从/api/data/history接口拿，前端按时间排序后直接塞给ECharts的series.data即可。这里有一个经验：ECharts渲染大数据量时，如果历史数据几千条，直接把全部数据塞进去会导致图表卡顿，建议后端做分页或者前端做抽样，比如每10条取1条，图表依然能反映趋势。

4. 毕业论文怎么搭：从开题到定稿的骨架

论文的章节结构建议直接套用这个骨架，绝大多数学校的模板都认：

• 第一章 绪论：背景、国内外研究现状、研究内容与意义
• 第二章 相关技术介绍：SSM框架、Vue、蓝牙通信、WiFi通信、MySQL
• 第三章 系统需求分析：功能需求、非功能需求、可行性分析
• 第四章 系统设计：总体架构、模块设计、数据库设计、接口设计
• 第五章 系统实现：开发环境、核心功能实现、关键代码展示
• 第六章 系统测试：测试环境、功能测试、性能测试、测试结论
• 第七章 总结与展望

写论文最大的坑是“需求分析瞎编”。系统里明明只有设备管理和数据查看，却写了一大堆“智能预警”“自动报警”功能。答辩时评委随便点一个功能说“演示给我看”，你就傻眼了。我建议论文里写的每一个功能，都要在系统里真实存在并且可演示，宁可少写三个功能，也不要写一个做不出来的。

关键代码展示部分不用全部贴，贴核心的、能讲出设计思路的就行。比如：设备鉴权的拦截器、蓝牙数据解析的方法、数据库表设计的ER图、Vue的请求封装。每一段代码都要配至少200字的文字说明，解释为什么这么写，解决了什么问题。这部分是评审核查“工作量是否饱满”的重点区域。

测试章节要有真实的测试数据。把设备列表、实时数据截图、历史查询截图、登录页面截图都贴在论文里，表格形式列出测试用例和执行结果。特别注意：截图里的设备名称、数值、时间务必要前后一致，不能设备列表里是D001，数据曲线里却显示D002，这种低级矛盾被评委抓到非常影响印象分。

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

5.1 蓝牙模块连不上怎么办

蓝牙模块连不上是出现频率最高的硬件问题。我总结下来，90%的情况是以下原因之一：

第一，模块没有进入AT模式。HC-05进入AT模式需要按住模块上的按键再上电，此时模块指示灯慢闪，才能通过串口发送AT指令配置名称、密码、波特率。很多人没按按键就直接发指令，模块毫无反应。

第二，波特率不匹配。HC-05默认波特率常见的是9600或38400，而调试串口工具如果设置的波特率不对，收回来的都是乱码。建议先用AT+UART?查询当前波特率，再对齐串口助手的参数。

第三，配对码不对。HC-05默认配对码是1234，但有些模块出厂被改过。方法是用串口发送AT+PSWD?查询当前配对码，或者直接AT+PSWD=1234重置。

5.2 串口乱码怎么排查

串口乱码的本质原因几乎只有两个：波特率不一致、电压电平不匹配。

波特率问题好解决，把收发双方都设置为相同的值，ESP32的Serial.begin(115200)和串口助手的波特率都要选115200。电压电平问题更隐蔽——如果你的传感器是5V输出，而ESP32的GPIO是3.3V逻辑，直接连接时电平不匹配会导致数据位错误。解决方案是加电平转换模块，或者选用3.3V供电的传感器模块。

还有一种乱码是数据格式问题，比如你发送的是浮点数26.50，但接收端按字符串解析，中间多了空格或换行符，也会显示异常。建议发送端统一用Serial.println()，接收端按行读取并用trim()去除换行，避免半包和粘包。

5.3 Vue跨域问题怎么解决

前后端分离开发时，跨域是必踩的坑。表现是浏览器控制台报No 'Access-Control-Allow-Origin' header。

解决办法推荐以下组合：后端SpringMVC配置全局CORS过滤器，前端Vue配置proxy代理。两个都做，双保险。

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

前端vue.config.js里加：

devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这里有个细节：allowCredentials(true)时，allowedOriginPatterns不能为*，必须写具体的域名模式，否则部分浏览器会拒绝。我遇到过在Chrome正常、在Edge直接报错的情况，就是这个原因。

5.4 ESP8266连不上WiFi怎么办

ESP8266连接WiFi失败，排查顺序从易到难：

第一步，确认SSID和密码是否正确。密码里有特殊字符时，比如#、@，要确认字符串有没有被转义或者截断。

第二步，确认模块上电后的启动模式。ESP8266有些型号需要外部给EN引脚拉高，如果供电不足，模块会反复重启，表现为串口不断输出乱码。建议用独立5V电源供电，不要只用USB转TTL的3.3V形式驱动。

第三步，确认路由器信道和频段。ESP8266只支持2.4GHz频段，如果路由器开了5GHz，模块根本扫不到。另外，如果路由器开启了“AP隔离”，即使连上WiFi也访问不了局域网内的服务器，需要在路由器后台关闭隔离选项。

5.5 数据库存不下高频率数据怎么办

如果上报频率高、数据量累积快，数据库表会膨胀到一定程度后查询变慢。这里给一个不换大数据组件、在毕设范围内足够使用的方案：定期归档。

具体做法是在后端加一个定时任务，比如每天凌晨把report_time超过30天的数据从sensor_data表迁移到sensor_data_history表，然后在原表删除已迁移数据。定时任务用Spring的@Scheduled就能实现，代码量不大，但论文里可以写“系统具备数据归档策略，确保核心表性能稳定”，这比单纯整表查询高级得多。

6. 个人经验与后续扩展

整套流程走下来，我最想分享的经验有三条。第一条，硬件调试一定要有“最小链路”思维：先让蓝牙模块和电脑串口对上，再接入传感器，最后才连服务器，每一步都验证通过再往下走，否则出了问题根本定位不到是硬件还是软件。第二条，写日志和写注释是毕设能顺利答辩的最大护城河，我见过太多同学代码写完了，答辩时完全讲不清“这里为什么这么写”，不是因为他不懂，而是当时没留下任何文字记录，三个月后自己都忘了。第三条，论文里的截图和测试数据要提前留好，千万不要写完代码再补截图，一定先跑一遍完整流程，把每一步的截图都规范命名存起来，写论文时直接插。

这个项目后续扩展空间也很大。比如把ESP32换成支持边缘计算的设备，在设备端做数据预处理，只上报异常数据；或者给系统加一个简单的MQTT通道，替代HTTP上报，降低设备功耗；再或者用Vue 3 + TypeScript重构前端，把看板做成大屏模式，毕业设计展上会非常出彩。这些方向任何一个拿出来，都足够写成研究生的研究方向了。不过对本科毕设来说，先把当前这条链路跑稳，比追求任何花哨功能都重要。