每年到了做毕业设计的季节，后台和私信里就堆满了类似的提问："学长，物联网毕设题目怎么选啊""有没有那种看起来不水、但又不会把自己做崩的题目""我单片机基础很弱，敢选智能家居吗"。说实话，大多数人纠结的不是题目本身，而是根本不知道用什么标准去挑题。市面上流传的物联网毕设题目合集少说几十份，但真正能让人拿着当路线图、顺着做下来还能顺利答辩的，并不多。
所以我把这份题目清单按场景拆成了九大类，一共100个。整理原则很简单：不求每个都高大上，但要求每个都能落地，每个背后都对应着明确的技术栈和开发路径。顺便把怎么选主控、怎么挑云平台、怎么排开发节奏、哪些坑最容易踩，一并整理出来。不管你手里是STM32还是ESP32，是做硬件出身还是软件出身，应该都能在清单里找到适合自己的方向。
1. 动手选题前，先把这几件事想明白
1.1 毕设选题的五个判断维度
很多人选题目是"看到哪个顺眼就选哪个"，这是最危险的做法。毕设不是课程作业，它有一个完整周期，从开题、中期检查、系统实现到论文送审，前后至少三到四个月。题目选不好，后面每一步都是煎熬。
我建议大家用五个维度去卡一个题目：
- 可完成性：以你现在的能力，三个半月能不能做出一个能演示、能截图、能写进论文的完整系统。选题目时默认留给自己的余量是"能顺利做出来"，而不是"挑战一下极限"。
- 工作量饱和度：题目太简单，比如纯粹点个灯、采集个温湿度上云，评审老师一看就觉得工作量不够。但题目也不能复杂到涉及大规模并发、复杂的算法调优，那种容易把自己拖垮。
- 展示性：毕设最终要演示，要有视觉效果。纯后端的东西很难演示，至少要有一个大屏、一个APP界面、一块屏幕显示曲线，或者实体硬件动起来。选题目时想一下，答辩现场你能给老师看什么。
- 技术栈熟悉度：尽量选自己用过或至少学过的东西。如果选一个完全陌生的领域，意味着光踩环境坑就要花掉两三周。
- 延展性：同一个题目能不能在论文里写出"系统架构设计""关键模块实现""系统测试与分析"这几个章节，内容够不够支撑篇幅。空间太窄的题目，论文会写得很痛苦。
这五个维度不需要全部满足，但至少有四个是OK的，才可以纳入备选。
1.2 三类学生的选题策略
根据我带过的学生和身边人做毕设的实际经验，可以把人粗分成三类，对应策略完全不同：
第一类是嵌入式底子比较扎实，自己写过驱动、画过板子、跑过RTOS的。这类人适合选有技术深度的题，比如基于STM32+FreeRTOS的多任务系统、基于边缘计算的图像识别装置、基于LoRa的低功耗传感器网络。你的优势在硬件侧，题目就往硬件上靠，软件侧能跑通就行。
第二类是软件方向，熟悉Java、Python、前端，但单片机玩得少。这类人建议选平台应用类、可视化类的题目，把SpringBoot+MQTT+数据大屏这类技术栈吃透，硬件端用ESP32或NodeMCU这种开箱即用的板子，跑几个传感器就行。你的优势在软件侧，不要死磕底层驱动，那是拿自己的短板去拼别人的长板。
第三类是基础一般，只想顺利毕业的。这类人最稳妥的策略是"经典题目+小创新"。比如做一个基于ESP32的智能鱼缸水质监控系统，硬件就是温度、浑浊度传感器加OLED屏和舵机，软件就是OneNET平台加微信小程序，整套方案网上资料多到刷不完，只要自己从头搭一遍、理解关键代码，论文写得通顺，拿个中上成绩不难。
策略定下来之后，再看题目清单就有了明确的筛选标准。不符合自己定位的题目，再热门也直接跳过。
2. 100例选题清单：按场景分类整理
2.1 智能家居类（01-15）
智能家居类永远是物联网毕设的"流量担当"，因为它场景明确、演示效果好、技术栈通用。缺点是同质化严重，如果只是"ESP32+点灯"，基本拿不到高分。做这类题的关键在于加"场景联动"或"智能化策略"，而不是堆传感器。
- 01 基于ESP32与语音识别的智能家居控制系统
- 02 基于STM32的智能窗帘与光照自适应系统
- 03 基于OneNET平台的智能灯光场景联动系统
- 04 基于ESP8266的远程智能插座设计
- 05 基于STM32与多传感器融合的家庭安防系统
- 06 基于物联网的智能门锁与门禁系统
- 07 基于MQTT协议的智能家居私有网关设计
- 08 基于Android的智能家居远程监控APP
- 09 基于LoRa的无线智能家居组网系统
- 10 基于人脸识别的智能访客登记系统
- 11 基于语音交互的老人看护家居系统
- 12 基于RFID的智能收纳与寻物系统
- 13 基于ESP32-CAM的家庭异常检测机器人
- 14 基于STM32的智能鱼缸水质监控系统
- 15 基于物联网的智能晾衣架控制系统
这里我特别说一下07这个题目，智能家居私有网关，听着很唬人，其实就是用ESP32跑一个MQTT broker，让家里多个节点设备通过本地网关通信，不上云也能联动。这个题目的优势是能写出"本地化部署""数据隐私保护"这些加分点，工作量也适中，适合有一定网络基础的同学。
2.2 环境监测类（16-27）
环境监测类是另一个大热门，原因很简单：传感器好买、数据好测、云端展示模板成熟。哪怕是同样的温湿度采集，换个场景（校园、宿舍、车间、野外），就是一个新题目。这类题目的关键卖点在"数据采集的可靠性"和"多参数融合展示"，论文里可以写校准、误差分析、数据滤波这些实在的内容。
- 16 基于ESP32的室内空气质量监测系统
- 17 基于STM32的大气环境多参数监测站
- 18 基于OneNET的校园环境实时监测平台
- 19 基于Arduino的温湿度与光照自动记录仪
- 20 基于LoRa的野外环境数据采集系统
- 21 基于ESP32-CAM的烟雾火焰识别监测系统
- 22 基于树莓派的空气质量边缘计算监测系统
- 23 基于STM32与GPS的移动环境监测装置
- 24 基于物联网的噪声污染实时监测系统
- 25 基于ESP32的宿舍用电与温控监测系统
- 26 基于LoRa与太阳能供电的农业环境监测节点
- 27 基于无源RFID的环境感知标签设计与验证
27这个题目想多说一句，它涉及"无源物联网"的概念，核心是标签自身不带电池，靠射频能量驱动传感器工作，属于偏前沿的课题。优点是足够新，答辩时老师会感兴趣；缺点是参考资料少、调试难度大，只建议动手能力强、愿意啃论文的同学选。
2.3 智慧农业类（28-39）
智慧农业和校园类有点像，场景灵活性高，哪怕只是"给学校劳动教育基地的花圃做一个自动灌溉系统"，包装成"智慧农业"也能成立。这类题目的加分点是"控制闭环"——不只是采集数据，还要根据数据自动控制设备，比如土壤湿度低了就启动水泵。
- 28 基于ESP32的智能灌溉控制系统
- 29 基于STM32的温室大棚环境调控系统
- 30 基于OneNET的农业大棚远程监控平台
- 31 基于LoRa的农田墒情监测网络
- 32 基于树莓派与YOLOv5的农作物病虫害检测系统
- 33 基于ESP32-CAM的果园果实成熟度识别系统
- 34 基于物联网的智能养殖场环境管理系统
- 35 基于STM32的智能孵化箱设计与实现
- 36 基于ESP8266的阳台智能种植装置
- 37 基于物联网的水肥一体化控制系统
- 38 基于MQTT与SpringBoot的智慧农业管理平台
- 39 基于机器视觉的智能除草机器人
32和33都涉及边缘端的视觉识别，对应热搜词里经常被问的"基于STM32的边缘端YOLOv5车辆检测"那一类。这类题目的难点不在模型训练，而在如何把模型部署到端侧、控制推理延迟和内存占用。如果你没有跑过模型量化或TensorRT Lite这类工具，千万谨慎，别高估自己。
2.4 健康医疗类（40-49）
健康监测类这些年比较火，跟可穿戴设备、智慧养老的社会热点契合度高，老师一般比较买账。硬件端主要用到的传感器是心率血氧（MAX30102）、加速度计（MPU6050）等，价格不贵，代码库也很成熟。
- 40 基于STM32的便携式心率血氧监测仪
- 41 基于ESP32的老年人跌倒检测报警系统
- 42 基于OneNET的人体健康数据管理平台
- 43 基于物联网的智能药盒与服药提醒系统
- 44 基于MAX30102与Arduino的睡眠监测装置
- 45 基于ESP32-CAM的婴儿看护与哭声检测系统
- 46 基于STM32的智能轮椅控制系统
- 47 基于物联网的体质检测数据可视化平台
- 48 基于姿态识别的人体运动计数系统
- 49 基于蓝牙与低功耗技术的医疗设备数据传输系统
这里想提醒一句，涉及健康数据、医疗场景的题目，在论文里要注意措辞。你做的不是医疗器械，而是"辅助监测原型系统"，千万不要在论文里写"可以实现疾病诊断""用于临床治疗"这类表述。我自己见过有同学论文里写了"可辅助诊断心血管疾病"，结果被评审老师毫不客气地指出了，这在工程伦理和合规性上都是隐患。
2.5 智慧校园类（50-61）
智慧校园类题目适合还没想好场景的同学，因为"校园"本身就是个极其丰富的大场景：图书馆、教室、实验室、宿舍、食堂、体育馆，随便挑一个角落都能出题。这类题目跟自己的生活贴近，需求分析好写，调研起来也方便。
- 50 基于RFID的图书馆座位预约与管理系统
- 51 基于ESP32的智能教室灯光与空调联动系统
- 52 基于OneNET的实验室设备远程开关系统
- 53 基于物联网的校园快递取件通知系统
- 54 基于STM32的智能黑板清洁与空气质量联动系统
- 55 基于ESP32-CAM的课堂出勤自动识别系统
- 56 基于人脸识别的宿舍门禁系统
- 57 基于物联网的实验台用电安全监测系统
- 58 基于LoRa的校园环境双碳数据采集系统
- 59 基于Android的校园失物招领物联网平台
- 60 基于RFID的实验室仪器借还与追溯系统
- 61 基于物联网的体育馆预约与灯光联动系统
58这个题目涉及低碳和节能概念，这两年关注度高，其实实现起来就是环境数据采集加能耗估算，但包装得好就能成为亮点。我在实际指导中见过类似选题，学生做了一个校园路灯能耗监测系统，把每盏路灯的用电量、光照度、开关状态都汇总到一张大屏上，论文里的"能耗分析"章节写得相当出彩。
2.6 工业与物流类（62-73）
工业类题目最大的优点是"看起来有工程价值"，评审老师普遍认为这类题目更有实际意义。但难点也很明显：真实的工业环境你接触不到。解决办法是"场景仿真"，比如用传送带模型、小型机械臂模型、立体车库模型来模拟工业现场。
- 62 基于STM32的车间温湿度监测与报警系统
- 63 基于OneNET的工业设备运行状态远程监控
- 64 基于MQTT与Netty的物联网智能充电桩管理系统
- 65 基于RFID的仓储货物自动盘点系统
- 66 基于ESP32的冷链运输温度监控系统
- 67 基于机器视觉的工件尺寸检测装置
- 68 基于LoRa的工业现场无线传感器网络
- 69 基于物联网的智能立体车库管理系统
- 70 基于STM32与PLC通讯的产线数据采集系统
- 71 基于ESP32-CAM的工业仪表读数识别系统
- 72 基于UWB定位的仓库人员物资定位系统
- 73 基于无源RFID的物流包裹分拣追踪系统
64这个题目跟热词里的"SpringBoot 3.x + Netty + MQTT 物联网智能充电桩"高度相关。它其实是一个非常典型的"物联网后端"题目，硬件端是充电桩模拟器，通过MQTT上报充电状态，后端用Netty做TCP长连接接入，SpringBoot提供业务接口。如果你Java底子不错，这类题目容易出彩；如果你没接触过Netty，建议先花一周把Netty的核心概念过一遍再决定。
2.7 城市与交通类（74-83）
城市交通类的题目适合想结合"大场景"和"民生需求"的同学。跟智慧校园同理，场景真实、痛点明显，比如停车难、交通拥堵、共享单车乱停放。这类题目做的时候不需要真的部署到城市里，通常用沙盘或仿真环境演示即可。
- 74 基于STM32的智能停车场车位引导系统
- 75 基于ESP32-CAM的交通流量检测系统
- 76 基于OneNET的共享单车停放管理平台
- 77 基于GPS与物联网的公交到站预报系统
- 78 基于LoRa的路口交通灯自适应控制系统
- 79 基于物联网的电动车智能防盗追踪装置
- 80 基于树莓派的道路积水实时监测系统
- 81 基于RFID的BRT快速公交免停车过站系统
- 82 基于ESP32的驾车疲劳监测与提醒装置
- 83 基于物联网的城市停车充电一体化平台
选择交通类题目时，要注意一个问题：很多题目看起来是"城市级别"，但毕设只能做"实验室级别"的演示。所以论文里一定要写清楚"系统设计为可扩展架构，受限于实验条件，本设计以缩小比例场景进行验证"，这种表述既是实事求是，也是保护自己。
2.8 平台与应用类（84-91）
如果你不想太折腾硬件，平台类题目是最佳选择。这类题目的核心是"软件平台能力"：设备接入、消息处理、数据存储、API接口、前端可视化。硬件端只需要买一两个现成的开发板跑数据上来就行，甚至可以用模拟器产生数据。
- 84 基于SpringBoot与MQTT的物联网设备管理平台
- 85 基于Netty的物联网网关消息中间件设计
- 86 基于OneNET云的设备数据大屏可视化系统
- 87 基于ESP32与微信小程序的智能家居控制平台
- 88 基于MQTT的物联网设备影子与管理平台
- 89 基于Flask的传感器数据RESTful API服务设计
- 90 基于EMQX的分布式物联网消息接入平台
- 91 基于数字孪生的设备运行可视化系统
85和90偏向中间件和消息接入，适合对网络编程、高并发感兴趣的同学。数字孪生91这个题目这两年很火，但要注意，毕设里的数字孪生不需要做到完整一比一仿真，通常是用Unity或者网页3D技术做一个设备的三维模型，把实时数据驱动到模型上。只要"以虚映实"的逻辑讲通了，就是一篇合格的毕设。
2.9 嵌入式基础类（92-100）
最后一类偏底层和算法，适合有嵌入式开发经验、不想做太多业务逻辑的同学。这类题目最大的优势是"技术壁垒"——答辩时老师不能只看个外观，得认真看你怎么实现多任务调度、怎么优化功耗、怎么处理实时性。但也是"劝退型"题目，新手慎入。
- 92 基于FreeRTOS的STM32多任务嵌入式系统设计
- 93 基于ESP-IDF的ESP32低功耗数据采集节点
- 94 基于RT-Thread的智能硬件原型系统
- 95 基于Arduino与传感器阵列的数据融合实验平台
- 96 基于边缘计算的端侧图像识别装置
- 97 基于声学传感的管道泄漏检测装置
- 98 基于振动传感的电机故障诊断系统
- 99 基于光通信的室内定位系统
- 100 基于蓝牙Mesh的多节点组网照明系统
93题涉及ESP-IDF，跟Arduino环境完全是两个世界。ESP-IDF用esp-idf工具链，需要自己写CMakeLists，使用FreeRTOS的API，学习曲线陡很多，但换来的是低功耗控制和更灵活的底层能力。想做低功耗方向的同学，一定要在这个题目上预留足够的学习时间。
3. 拿到题目后，技术选型怎么定
3.1 主控芯片选型别只看芯片本身
很多同学选主控只看一句话"STM32比ESP32强"或者"ESP32有WiFi所以更好"。实际选型要综合考虑三件事：开发效率、资料丰富度、毕业设计的需求匹配。
如果你选的题目需要联网、需要对接云平台、需要做可视化，那么ESP32系列几乎是默认答案。原因很简单：ESP32自带WiFi和蓝牙，用Arduino框架写代码，基本就是"点一下烧录就能跑"。而如果用STM32，你要么外挂ESP8266模块，要么用W5500以太网模块，多一层硬件调试就多一分不确定性。反过来，如果题目偏工业控制、偏底层实时性、需要丰富的定时器和外设，那STM32的生态更合适，HAL库配合CubeMX配置工具，开发速度也还可以。
这里补充一个细节，很多题目清单里会出现"基于STM32+ESP8266+OneNET"这种组合，这是前些年的"标准套餐"。但现在我更推荐直接用ESP32替代STM32+ESP8266的组合，一个是芯片集成度高、故障点少，另一个是ESP32的算力和外设足以跑小型应用。除非题目明确写了必须用STM32，否则没必要自讨苦吃。
还有个容易忽略的点：先确认你手头有什么开发板和模块。如果实验室积灰的板子恰好是STM32F407，你就围绕它选题目，而不是选了一个树莓派的题再花钱买板子。省钱省时间，还能少一个"物流等待"的变量。
3.2 云平台和通信协议：OneNET、MQTT还是自建后端
联网是物联网毕设的核心环节，云平台这块的选择基本决定了你的开发路径。目前学生党用下来的结论比较统一：国内用OneNET或多协议物联网开放平台，简单省事，设备接入、数据存储、可视化图表都是现成的，还有大量教程和Demo。如果你主要目标是把接入和展示做出来，选OneNET类平台肯定最快。
如果你的题目偏软、偏平台本身，比如84、85、90这几个题目，就要自己搭建后端。技术组合上最主流的是SpringBoot+Netty+MQTT。SpringBoot负责业务API，Netty负责TCP和MQTT长连接接入，MySQL存设备数据，前端用Vue或ECharts做可视化。这个组合踩坑点在学习成本上，但做完以后你简历上能写的东西也多一截。
通信协议层面，物联网毕设基本就是MQTT的天下，原因也很直白：协议轻量、发布订阅模型适合多设备场景、各个云平台都原生支持。LoRa、NB-IoT这些协议在毕设里属于"点缀"，用在特定题目里能加分，但不建议作为主通信方式，因为模块贵、调试费劲、实际效果也不容易展示。
3.3 前端和可视化：直接决定答辩效果
这部分很多人不重视，其实相当关键。答辩现场老师看的最多的就是你的演示界面。哪怕硬件做得再花哨，界面一团糟，印象分会掉得很厉害；反过来，一个干净清爽的大屏或者小程序界面，能直接把项目的完成度拉高一个档次。
技术选型上，我见过的最稳组合是：OneNET平台提供的数据可视化工具，或者用Vue+ECharts自己搭一个数据大屏。前者适合不想花时间写前端的同学，后者适合软件底子不错、想在论文里写"前端基于Vue框架"的同学。微信小程序也是很好的选择，因为答辩时可以直接手机投屏，演示效果非常直观。如果你要做实时数据曲线，优先看ECharts的折线图组件，OneNET和主流物联网平台基本都内置了折线图绘制能力。
4. 从选题到论文：一条完整的落地路径
4.1 第一周：需求分析、功能拆解和风险清单
拿到题目后的第一周不要急着写代码、接硬件。先做一个需求分析文档，把系统分成三个层次：感知层、网络层、应用层。感知层写清楚用哪些传感器、采集哪些数据；网络层写清楚用WiFi、LoRa、MQTT还是4G；应用层写清楚数据存哪里、怎么展示、用户有哪些操作。
然后做功能拆解，把所有功能按"必须有""最好有""可选"三档划分。比如做一个智能鱼缸系统，"必须有"是温湿度采集、自动控温、数据上云；"最好有"是远程喂食；"可选"是鱼病识别。"必须有"的功能保证做完，"可选"功能放到最后，有时间再补。这条底线一定要守住，否则做到后期你会为了一个"可选"功能把自己拖死。
最后列一份风险清单：哪些硬件可能缺货、哪些模块资料少、哪些功能可能做不出来（比如人脸识别精度不够、语音识别率低）。针对每个风险想好Plan B。我的习惯是Plan B永远选一个成熟方案，比如主控烧了就用备用板，识别模型跑不动就退级为实验仿真，先保证系统能演示。
4.2 硬件开发阶段：先点亮，再联调
硬件开发的节奏应该遵循"最小系统先行"的原则。不管你的系统最后有多复杂，第一步都是先把一个最简单的链路跑通：主控板通电、传感器出数据、OLED或串口能看到数据。这一步跑通了，后面都是惯性推进；这一步卡住，多半是硬件连接或供电问题。
我看到很多人在这个阶段犯的最大错误是"一上来就全模块接入"。传感器接了五六个，代码写了一堆，结果数据全乱，根本不知道是哪个模块的问题。正确做法是每次只接一个模块，数据确认正确后再接下一个。每加一个模块就做一次完整验证，像搭积木一样叠加，问题定位会快很多。
供电问题要特别提醒。ESP32和多个传感器同时工作，电流需求很容易超过USB口供给能力，表现为系统反复重启或传感器读数异常。解决办法是用独立5V/2A电源给主板供电，传感器用统一电压供电，切忌传感器和舵机共用一路电源。
4.3 软件联调阶段：先模拟数据，再真实数据
硬件端和软件平台联调时，最容易卡住的是"数据一直传不上来"。我的经验是先不要用真实传感器，直接用代码循环发送模拟数据，比如每隔两秒发一个递增的温度值，先确认MQTT链路、云平台接入、数据库写入端到端是通的，然后再切到真实传感器数据。这样能把"硬件问题"和"软件问题"两个变量彻底分开。
联调时要养成看日志的习惯。ESP32用串口监视器打印状态信息，后端用日志框架记录消息收发记录。出现数据丢包时，先查MQTT的QoS配置，再查网络延迟。毕设场景下大多数数据丢失是信号弱或发送频率过高导致，把上报频率降到1到5秒一次基本就稳定了。
4.4 论文写作：边做边写，不要最后突击
论文是最容易被拖延的部分，却是最能拉开成绩差距的部分。我的建议是"边做边写、分段完成"。开发阶段就同步写需求分析和系统设计章节，联调阶段边写系统实现，测试阶段写系统测试和分析。最后留两周统一修改格式、补图表、写摘要和结论即可。
论文配图的规范要早定：系统架构图、硬件连接图、功能流程图、时序图、界面截图、实验数据表、测试结果对比图，至少要有15张以上。图片要清晰、有编号、有标题，正文里要有对应引用。封面、目录、参考文献格式从第一稿就按学校模板来，避免最后统一改格式时血压飙升。
至于查重，这里多说一句：不要试图用翻译或同义词替换来降重，那只会让论文读起来很怪。正确做法是理解技术原理后用自己的话重新组织，实验数据、测试过程这些"自己做过"的内容天然不重复，这也是为什么强调要自己动手做系统的原因。
5. 常见问题与避坑指南
5.1 选题阶段最容易踩的坑
- 题目太大，做不完。"基于物联网的智慧城市管理系统"这种题目，一看就是坑，光需求能写一本书。毕设题目要小切口、深挖掘，宁可做一个具体的"智能停车场车位引导"，也不要做泛泛的"智慧城市"。
- 题目太旧，没新意。"基于51单片机的温湿度采集"这种题目大概率会撞车，而且技术栈停留在十年前。同一件事换一个技术栈或者加一个智能策略，就是新题目。
- 完全没接触过的技术栈。如果题目要求你没接触过的东西占比太高，比如完全没碰过前端却选了一个重前端的题目，学习成本会吞噬你的开发时间。选一个"大部分会+小部分学"的题目才是最优解。
5.2 开发阶段的高频事故
- 硬件模块不兼容，比如传感器是3.3V逻辑，接在5V单片机上就会烧模块。买模块前一定要确认工作电压和逻辑电平。
- 云平台接入失败，多半是产品ID、设备密钥填错，或者产品模型和数据流模板没建对。OneNET类平台要先在网页端把产品和数据流建好，再在代码里填对应的鉴权信息。
- 数据上去了，但不更新，大概率是脚本订阅了Topic却忘了处理消息，或者数据流名称大小写对不上。
- 电源供电不足，系统反复重启，设备一直处于"掉线-上线-掉线"循环。前面说过，独立供电是最有效的解法。
5.3 答辩前夜的突击事项
答辩前一周，除了把系统跑熟之外，还要做三件事。第一，准备一个"演示故障预案"，把演示过程中可能出现的翻车场景准备好话术，比如"由于现场网络原因，我们切换到本地缓存数据演示"，这句话说出来，老师会理解，不会死磕。第二，把论文里的核心图表位置记清楚，老师问起的时候能快速翻到对应页码，这是一种很有用的"专业感"。第三，练一遍5分钟演讲：背景与意义、系统架构、核心实现、演示、总结，每个环节卡时间，不要超时。
5.4 常见问题速查表
| 问题 | 原因 | 处理方案 |
|---|---|---|
| 硬件上电反复重启 | 供电电流不足 | 改用独立5V/2A电源 |
| 传感器数据明显异常 | 电源噪声或接线虚接 | 重新插拔杜邦线，传感器与电机分路供电 |
| 设备上云失败 | 鉴权信息错或模板未建 | 核对产品ID、设备密钥、数据流名称 |
| MQTT消息偶尔丢失 | QoS级别低或发送过快 | 使用QoS 1，上报间隔调到2秒以上 |
| 上位机/小程序无数据 | Topic订阅错误或数据处理未写 | 检查订阅Topic，补充消息处理回调 |
| 演示现场设备掉线 | 现场WiFi限制终端隔离 | 准备手机热点做备用网络 |
| 视觉识别卡顿 | 模型在端侧推理耗时过长 | 换轻量模型或降低输入分辨率 |
| 论文查重偏高 | 大量复述教程内容 | 用自己的语言重写，突出实验测试部分 |
写在最后的一点经验
我自己从本科到带项目这些年，最大的感受是：毕设能不能做好，往往在选定题目的那一刻就决定了七八成。选一个你愿意天天碰的题目，比选一个看起来高级但每次打开都头疼的题目，最终结果会差出好几个档位。如果你还在犹豫，不妨从第2章的清单里挑出三个第一眼就有感觉的题目，分别对比一下技术栈，选那个你愿意为它多花时间折腾的。
最后再分享一个小技巧。不论选了哪个题目，第一天就把整个系统的架构图画出来，哪怕很粗糙，哪怕后期要改。先画面，再搭骨架，再填肉。这种做法能让你在接下来的一两个月里始终清楚自己做到哪一步、下一步该干什么，而不是被各种细节推着走，走到哪算哪。祝你们都能顺顺利利把毕设做完，答辩的时候能底气十足地说一句"这个系统是我从头到尾做出来的"。
