1. 物联网技术架构到底是什么
聊物联网之前，我一直觉得有个坎儿绕不过去——所有人都在说物联网，但问一句"物联网的技术架构到底长什么样"，十个人里至少有五个会卡壳。剩下五个里，三个说是三层架构，两个说是四层架构，还有个把OSI七层模型直接搬过来硬套。说来说去，都是一堆概念名词往上堆，真正能把这套架构讲透、讲明白、讲得能动手落地的，没几个。
我刚入行做嵌入式那会儿，也是这样。芯片选型、传感器调试、协议对接，每一项都是深坑，忙活半天联调联不通，后来才意识到问题不在某个具体模块，而是我对物联网的技术架构没有形成全局认识。就像盖房子，你天天研究砖头水泥怎么用，但不知道整栋楼应该是几层、墙在哪、楼梯怎么走，这活干不下去。
这篇文章就是我把自己这些年做物联网项目的经验，从架构层面重新梳理了一遍。从感知层到平台层，从通信协议到云端应用，每一层该干嘛、怎么选型、踩过什么坑，都写清楚。不管你是刚接触物联网的新手，还是准备做毕业设计的学生，或者已经在做物联网开发但总觉得知识碎片化，这篇内容应该都能帮到你。
2. 三层还是四层？一张图看懂物联网技术架构
2.1 最经典的三层架构：感知、网络、应用
教科书里最常见的物联网技术架构是三层——感知层、网络层、应用层。这个分法简单、好记，大学教材基本都这么讲。
感知层负责"感知世界"，核心是把物理世界的温度、湿度、位置、图像、开关状态等信息变成数字信号。典型设备就是各种传感器、摄像头、RFID读卡器、GPS模块，以及把这些东西串起来的单片机（MCU）或者边缘网关。说白了，感知层解决的是"数据怎么来"的问题。
网络层负责"传递数据"，把感知层采集到的数据从设备端传到服务器端。这里涉及非常多的通信技术和协议——近距离的有Wi-Fi、蓝牙、ZigBee，远距离的有4G/5G、LoRa、NB-IoT，应用层的协议主要是MQTT、CoAP、HTTP这类。网络层解决的是"数据怎么传"的问题。
应用层负责"处理数据、提供服务"，把接收到的数据存储、分析、展示，形成具体的业务价值。比如环境监测系统里的温湿度大屏、智慧农业里的自动灌溉控制、充电桩管理系统里的远程监控，都属于应用层的范畴。应用层解决的是"数据怎么用"的问题。
这三层架构理解起来非常直观，也是很多物联网从业者脑子里的基础模型。但真正落地的时候你会发现一个问题——光有这三层，项目根本跑不起来。
2.2 为什么实际项目里要再加一个平台层
我从2017年开始接手物联网项目，做过智能家居网关，做过环境监测系统，也做过工业设备远程监控。纯用三层架构去套这些项目，总感觉中间缺了一大块东西。设备数据确实通过网络传到了服务器，然后呢？谁来管设备的接入？谁来处理设备的在线状态？谁来存海量的时序数据？谁来给应用层提供统一的API接口？
这些工作，既不属于感知层，也不完全属于网络层，更不能直接算应用层。所以在实际工程里，大家都默认加了一层——平台层，也叫支撑层。平台层一般包括设备接入网关（负责协议解析、设备鉴权）、消息中间件（负责数据流转）、规则引擎（负责处理上下行数据）、数据存储（时序数据库、关系型数据库）等核心组件。
四层架构才是物联网项目真正跑起来的基础。感知层解决数据来源，网络层解决数据传输，平台层解决设备管理，应用层解决业务展示，每一层都有自己要啃的硬骨头。
拿我去年带学生做的ESP32环境监测项目来举例。温度传感器采集数据，这一步是感知层；ESP32通过Wi-Fi把数据用MQTT协议发到服务器，这一步是网络层加平台层——服务器上需要有一个MQTT Broker接收消息，还要有后端服务消费消息并写入数据库；最后做一个网页或者小程序展示温湿度曲线，这就是应用层。如果只按三层架构教学，学生做完设备端就没了，平台层和应用层的核心工作量完全体现不出来。
2.3 用一个口红的例子把架构讲明白
有个特别有意思的说法，叫"物联网起源口红说"。这个故事在物联网圈子里流传很广：据说宝洁公司的某个高管发现某款口红在货架上缺货了，但供应链系统完全没感知到，导致补货不及时，白白损失了销量。这件事让他意识到，如果能让货架上的商品主动"开口说话"，实时告诉供应链自己还有多少库存，就不至于出现缺货问题。后来这便被看作是物联网（尤其是RFID感知方向）早期概念形成的重要契机。
不管这个故事的细节是否被演绎过，它确实讲明白了物联网的核心逻辑——让物理世界的物品具备"数字化表达能力"。我用这个故事给学生讲架构时，他们会记得特别牢：
- 口红的包装上贴RFID标签，货架上的读卡器感知到它在不在——感知层。
- 读卡器把数据通过Wi-Fi或者有线网络传到后台——网络层。
- 后台系统判断库存不足，触发补货提醒——平台层和应用层。
- 店长的手机上收到"3号货架口红缺货"的推送——应用层。
你看，一条链路下来，物联网技术架构的每一层都有了非常具体的对应物。理解架构最怕空对空，找到一个具体的物、具体的场景，把每一层套进去，比死记硬背定义管用一百倍。
3. 感知层实战：传感器选型、主控芯片和无源物联网
3.1 感知层的4个核心组件
感知层虽然看起来就是"传感器加单片机"，但真正要落地得拆细。我在实际项目里一般把感知层拆成四块：
第一是传感器本身。温度、湿度、光照、PM2.5、人体红外、土壤湿度、GPS定位等等，不同类型的传感器选型和接口方式差别很大。DHT11便宜但精度一般，适合学习；SHT30精度高、稳定性好，适合实际项目。土壤传感器有电容式和电阻式之分，电容式不容易腐蚀，寿命长很多。
第二是主控芯片。这是感知层的大脑。做简单的传感器采集，用STM32、ESP32、Arduino都行。ESP32这几年火得不行，集成Wi-Fi和蓝牙，价格便宜，生态成熟，做物联网原型验证和实际产品都够用。这也是为什么热词里总能看到"ESP32物联网项目"的原因——它实在是太适合做物联网设备端了。
第三是电源管理。这个很多人容易忽略，但实际项目里十个问题有八个出在电源上。一节18650电池到底能撑多久？用稳压芯片还是LDO？睡眠模式的功耗是多少？如果做的是野外环境监测，电池和功耗估算就是主要矛盾。有些项目要求使用无源物联网方案，直接从环境取电，对功耗的要求更是苛刻到微安级别。
第四是执行机构。感知层不只是采集数据，有时候也要做动作。继电器控制灯光开关、水泵启停，步进电机控制阀门，这些执行机构的驱动电路也是感知层的一部分。这里就遇到一个经典问题——单片机的IO口驱动能力不够怎么办。
3.2 ULN2003A救急方案：IO驱动能力不够的经典解法
很多新手在物联网项目里会遇到这个场景：ESP32或者STM32的IO口输出电流只有几毫安到二十毫安，直接驱动一个5V继电器或者一个步进电机，电流根本不够。IO口本身没坏，但负载动不了，或者单片机被拉复位。这时候ULN2003A就是那个经典的救急方案。
ULN2003A本质上是一个达林顿晶体管阵列，内部集成了7路达林顿对管，每一路可以承受500mA左右的电流，耐压50V。你的单片机只需要输出一个逻辑高电平，ULN2003A就能把这个信号放大成能够驱动继电器线圈、步进电机绕组、小功率电磁阀的电流。
用的时候有几个关键点必须注意：
- 必须共地。ULN2003A的GND和单片机的GND要接到一起，否则信号无法构成回路。
- 感性负载（继电器、电机）必须并联续流二极管。ULN2003A内部其实已经集成续流二极管了，但如果你用的是单独的达林顿管或者逻辑芯片，一定要外接二极管，不然关断瞬间的反向电动势能直接把器件打坏。
- 输入侧要接限流电阻。虽然ULN2003A的输入可以直接接3.3V或者5V逻辑电平，但很多设计里会在输入端加一个1k左右的电阻做保护，防止电流过大。
- 公共端COM脚要接负载电源正极。这一步经常有人漏掉，导致继电器不吸合，排查半天发现自己根本没有接COM脚。
我以前带过一个农业大棚监控项目，用ESP32控制三个继电器去切水泵和风机，最开始直接拿IO口去驱动继电器模块，结果接手时发现继电器模块上的三极管已经烧了一路。后来老老实实换了ULN2003A方案，一路驱动一路，7路里用3路，余量充足，运行了快一年再没出过问题。驱动这块，凡是遇到"IO口不够/驱动能力不够"的，先别急着换主控芯片，用ULN2003A低成本扩一下，往往是最快的解决路径。
3.3 无源物联网：感知层的新方向
热词里出现了一个"无源物联网"，我多说两句。这个概念这几年在物联网圈子里热度上升很快，核心思路是让终端设备不依赖电池或者少依赖电池，从环境里取电——太阳能、温差、射频能量、振动能量都可以成为供电来源。
最典型的是无源RFID标签，读卡器发射射频信号，标签通过整流电路把射频能量转为直流电，然后回传数据。它没有电池，成本极低，寿命极长。在资产管理、仓储盘点、物流追踪这类场景里，大量部署无源标签非常划算。
但无源物联网不等于只能用RFID。现在也有人在做环境能量收集的温湿度传感器，利用温差或者微弱光照给低功耗芯片供电，实现几年免维护的采集节点。不过这类方案目前最明显的短板是通信距离和数据量受限——你想想，一个微瓦级的设备，连发一条几百字节的报文都得省着来，所以目前落地最多的还是低频采集、短报文、长周期的应用场景。
如果你要做毕业设计或者产品预研，无源物联网是一个很有前景的方向，但别把目标定得太激进。先做一个用小型太阳能板给ESP32供电的低功耗节点，数据5分钟上报一次，电池只是作为备用，这样既能在一定程度体验"无源"的思路，又不至于陷入能量采集的深坑。
4. 网络层和平台层：协议怎么选、云平台怎么搭
4.1 通信方式选型：没有最好的协议，只有最合适的场景
网络层是物联网技术架构里最碎片化的一层，因为可选的通信方式实在太多了。我经常和同行开玩笑说，做物联网方案选型，一半的时间都花在纠结通信方式上。
近距离通信里，Wi-Fi适合数据量大、供电充足的室内设备；蓝牙BLE适合低功耗、短距离、手机直连的穿戴设备；ZigBee适合自组网的智能家居场景，但实际家用普及度远不如Wi-Fi和蓝牙Mesh。
远距离通信里，4G/5G覆盖广、速率快，但模块贵、功耗高、要插SIM卡；LoRa适合几十公里级别的低速率自组网，但要自己部署网关；NB-IoT适合表计、井盖这类窄带广覆盖场景，功耗低，运营商基站覆盖到位的话体验很不错。
做项目选型时，我一般先列三个问题：数据量大不大？供电方便不方便？部署距离远不远？把这三个问题想清楚，通信方式基本就定个八九不离十了。反过来，上来就纠结LoRa和NB-IoT哪个好，而不说场景，那是耍流氓。
4.2 MQTT协议为什么是物联网事实标准
网络层的协议，MQTT值得单独拿出来讲。它几乎是目前物联网设备接入的事实标准——阿里云物联网平台、EMQX、EMQ X Cloud、AWS IoT Core全都原生支持MQTT。
MQTT是发布/订阅模式的消息协议，服务端叫Broker，设备可以发布消息到某个主题（Topic），也可以订阅某个主题来接收消息。这个模式和HTTP的请求/响应模式完全不一样。设备上报数据，只需要往指定Topic发布一条消息，不需要等服务器回复，天然适合物联网场景里的高频小数据量传输。
MQTT还有一个宝藏特性叫遗嘱消息（Last Will and Testament）。设备上线时可以设置一条遗嘱，如果设备异常掉线，Broker会自动替它发布这条遗嘱消息，后端服务就能立刻感知设备离线了。这个特性在设备状态管理里非常有用，我做过几个项目都靠它自动标记离线设备。
还有一个就是QoS服务质量等级。QoS 0最多发一次，可能丢消息；QoS 1保证至少到达一次，可能重复；QoS 2保证恰好一次。实际项目里，遥测数据用QoS 0问题不大，控制指令建议用QoS 1，丢失和重复都不太能接受。
热词里出现的SpringBoot 3.x + Netty + MQTT实战物联网智能充电桩项目，就是一个很典型的学习案例。设备端走MQTT上报充电状态，后端用Netty做TCP长连接去对接充电桩的私有协议，再通过MQTT把解析后的数据交给SpringBoot业务模块处理。这种架构在国内物联网项目里非常常见——设备协议五花八门，先接入到网关，再统一转成MQTT消息进入业务系统。
4.3 云平台选型：阿里云物联网平台和自建方案怎么取舍
做物联网项目，平台层的建设有两条路：一是直接用云厂商的物联网平台，比如阿里云物联网平台；二是自己部署开源的MQTT Broker加后端服务。
阿里云物联网平台最大的优势是省事。设备接入、设备影子、物模型、规则引擎都是现成的，控制台里把产品定义好，生成设备三元组（ProductKey、DeviceName、DeviceSecret），设备端用官方SDK接入就行。做产品原型、参加竞赛、快速交付项目，这是效率最高的选择。
不过这里有个现实问题——阿里云物联网平台的公共实例在某些时段和区域新购有限制，不少用户想新购发现买不了。这个不展开讲具体政策，但如果你遇到类似情况，替代方案有三个：
第一个方案：阿里云还有其他类型的实例可选，留意一下企业版实例或按量付费的新规格，有时只是页面入口变化。
第二个方案：用EMQX自建一个MQTT Broker。EMQX是开源的，单机支持百万级连接，部署在云服务器上，再写一个后端服务消费设备消息，功能上完全能替代云厂商物联网平台。唯一代价是运维成本上来了，要自己管证书、管监控、管高可用。
第三个方案：如果项目规模不大，用云服务器直接装一个轻量级的MQTT Broker（比如Mosquitto）也能跑起来。适合学习、毕业设计、中小规模项目。
选型的核心逻辑很直接：时间紧、规模小、想快速出成果，用云厂商平台；规模大、定制化需求高、不想被平台绑定，就自建。别盲目崇拜某一种方式。
4.4 网络层到平台层的完整数据链路长什么样
把网络层和平台层放在一起看，一个典型的数据链路是这样的：
设备端传感器采集数据 -> 单片机（ESP32等）处理成JSON格式 -> 通过MQTT发布到某个Topic -> MQTT Broker收到消息 -> 后端服务订阅Topic消费消息 -> 解析校验 -> 存储到时序数据库 -> 业务规则判断（比如温度过高则下发报警或控制指令）-> 通过MQTT下行指令让设备执行动作。
这个链路里，每一环都有坑。设备端的JSON字段名要和平台层约定好，大小写、单位、取值范围都要提前定义。这类工作现在可以用物模型来解决，把设备的能力（属性、事件、服务）标准化，设备端和平台端都按物模型来对接，比一个一个字段口头对齐靠谱得多。
平台层的消息消费要特别注意幂等性。设备重复上报一条消息，数据库里不能出现两条重复记录；下行指令下发时，设备执行了但回复丢了，下次要不要重发？这些问题在设计阶段就要想清楚，不然数据多了之后全是要返工的事。
5. 应用层：数据怎么变成用户能看懂的东西
5.1 应用层的典型业务形态
物联网的应用层，我理解的本质是"把设备数据包装成用户能用的功能"。同样是温湿度数据，放在环境监测大屏上是一个样子，放在智慧农业自动灌溉系统里又是另一个样子。数据本身是死的，应用层让数据产生业务价值。
常见的应用形态有这几类：
- 可视化监控：把设备上报的数据用图表、地图、大屏展示出来。这是最基础也最常见的，技术栈可以是网页、小程序、App或者专门的组态软件。
- 告警通知：设备数据超出阈值时，通过短信、邮件、App推送、钉钉/企微机器人通知运维人员。这里最怕的是告警风暴，设备一断连几百条告警同时涌出来，反而把真正重要的问题淹没了。
- 远程控制：用户在App或者网页上点击按钮，指令经过平台层下发给设备，设备执行开、关、调节等动作。控制指令的可靠性和安全性都要专门设计，不是简简单单发一条消息就行。
- 数据分析和预测：对历史数据做统计、预测性维护、能耗分析等。这是物联网应用层价值最高的部分，也是门槛最高的部分。
在项目落地时，应用层往往不是单独存在的。比如智能充电桩项目，应用层至少要包含充电状态实时显示、用户充电启动/停止操作、充电记录查询、计费结算几个模块。这些功能如果用代码来拆，就是一个标准的后台管理系统加上一个小程序端。
5.2 一块温湿度计到一张业务大屏的完整链路
我经常用"一座温湿度计怎么变成一张大屏"来给学生讲完整链路。这是所有做物联网的人都要过一遍的流程：
第一步，ESP32上电，连接Wi-Fi，建立MQTT连接。连接失败就重试，重试要有退避策略，不能一秒钟狂连十次。
第二步，读DHT11或者SHT30传感器数据，组装成一个MQTT消息，格式大概是：{"deviceId":"esp32-001","temperature":25.6,"humidity":58.3,"timestamp":1700000000000}，发布到名为device/esp32-001/data的Topic。
第三步，服务器上的MQTT Broker（比如EMQX）收到消息，订阅了对应Topic的后端服务（SpringBoot项目）消费消息，把数据写入时序数据库（TDengine、InfluxDB或者直接用MySQL都行）。
第四步，后端服务提供一个查询接口，返回最新一条数据和最近24小时的温湿度曲线数据。
第五步，前端页面（Vue/React或ECharts）定时或者通过WebSocket向后端请求数据，渲染成图表，展示在页面上。用户打开浏览器就能看到。
如果有告警需求，后端在写入数据的同时执行规则判断，如果温度大于某个阈值，就发送一条告警消息到钉钉机器人或者短信服务。
这个链路看起来简单，但每一步都有大量细节。比如时间戳用什么时区？设备端和服务器的时间不同步怎么办？前端图表刷新是用轮询还是WebSocket？设备离线了前端怎么显示？这些细节决定了一个物联网系统是真的好用，还是只能拿来演示。
5.3 绘制物联网应用系统的工作过程
热词里有一条"绘制物联网应用系统的工作过程"，这应该是很多学生在考试或者作业里碰到过的题。其实这道题的答案就在完整链路的图里：
- 信息采集：传感器和摄像头把外界信息转换成电信号。
- 信号处理：单片机（MCU）对信号进行数字化、滤波、格式化。
- 网络传输：通过无线或者有线网络把数据传输到远端服务器。
- 数据存储与分析：服务器接收、解析、存储数据，并进行分析。
- 应用响应：输出结果到终端界面，或者触发执行机构动作。
你画图的时候，把感知层、网络层、平台层、应用层的模块框出来，再用箭头把数据流向画清楚，是上行方向就标"数据上报"，是下行方向就标"指令下发"，基本就是标准答案了。
6. 新手怎么上手：学习路线、软件准备和毕设避坑
6.1 物联网学习需要什么软件
经常有人问，学物联网到底要装哪些软件。这个问题问得特别实在。我按使用场景整理一份清单：
硬件开发方面，Arduino IDE适合零基础入门，ESP32和很多传感器都有现成的库，几行代码就能读到一个温度值；如果要用ESP32做复杂一点的工程，VS Code加PlatformIO插件是更好的选择，代码管理、库管理都方便很多；STM32开发需要Keil MDK或者STM32CubeIDE，新手建议直接从CubeMX生成工程再写逻辑。
后端平台方面，至少要学会一种编程语言，Java（Spring Boot）、Python（FastAPI/Django）或者Node.js都行。数据库至少要接触MySQL，如果是海量时序数据，可以了解一下TDengine和InfluxDB。
消息中间件方面，最直接的入手方式是本地装一个Mosquitto或者用Docker跑一个EMQX，然后用MQTTX客户端手动连接、发布、订阅，把MQTT的机制玩明白，比写一百行代码都管用。
前端可视化方面，Vue或React任选一个，配ECharts做图表。如果不想写前端代码，也可以用Node-RED或者Grafana这些工具，拖拽式配置出数据面板。
工具软件的思路是"够用就好"，别一上来就把全家桶装齐，装完也不一定会用。用到什么学什么，学什么装什么，这是最省时间的路径。
6.2 物联网毕业设计怎么选方向
物联网相关的毕业设计，几乎每年都是热门。但很多学生的选题方式有问题——上来就问老师"您这里有没有题目"，或者上GitHub抄一个复刻，完全不管项目能不能做完、有没有技术含量。我根据常见的选题方向给几点经验：
环境监测类是最稳妥的。ESP32加几个传感器，用MQTT上云，做一个可视化界面，数据量不大、实现难度适中、演示效果也好。但正是因为太经典，想拿高分就得在细节上加分——边缘计算、低功耗、告警推送、数据预测，每加一点都是亮点。
智能家居类也很多，核心是设备联动。难点不在单设备控制，而在场景联动逻辑的合理性和稳定性。比如"温度超过28度自动开风扇"，这个逻辑看起来简单，但边界情况很多：风扇已经开着了要不要重复触发？手动关掉后自动控制会不会又把它打开？
充电桩、能耗采集这一类偏工业场景的选题，这两年越来越受欢迎，因为贴合实际、有竞争力。难点在于了解真实的业务逻辑和通信协议，比如Modbus RTU协议、充电桩的充电状态机。如果做这个方向，建议先找一套现成的协议文档看看，别着急写代码。
最后是选题的规模控制。毕业设计的周期一般就几个月，技术栈别铺太大。一个项目里如果既用了ESP32，又用了树莓派，还上了微信小程序和Web端，一个人做根本忙不过来。小而精、链路完整，远比大而全、到处是半成品要好。
6.3 关于物联网工程就业方向的几句实话
聊到物联网就业，网上说什么的都有。有说前景广阔的，有说劝退的。以我接触到的真实就业情况来看，物联网工程毕业生的去向大概分几个方向：
嵌入式开发方向，做底层驱动、MCU开发、RTOS，对C语言、电路基础要求高，工资和发展都还不错。这是很多物联网专业学生最对口的岗位。
物联网平台开发方向，偏后端，主要做设备接入服务、消息处理、数据存储，Java和SpringBoot是主流，熟悉云平台（阿里云IoT、华为云IoT）的会加分。
硬件测试和运维方向，做设备测试、现场实施、网络维护，门槛稍低，但对动手能力和责任心的要求反而更高。
解决方案方向，适合既懂技术、又懂沟通的人，主要负责给客户出技术方案，做需求分析。这类岗位对行业理解的要求很高，新手直接转方案工程师容易踩坑。
说实话，物联网这个行业最大的特点是"应用驱动"。它不像纯互联网岗位那样有一个统一的技术栈模板，而是跟着行业走——做智慧农业的，得懂一点农业知识；做智能制造的，得了解工厂的设备和流程。这个特点既是挑战，也是机会。愿意深耕某个行业的人，时间越长经验越值钱。
7. 常见问题与排查经验
做物联网开发，线上线下挨个排查问题，是最耗时间、也最涨经验的环节。这里我把这些年经常遇到的问题整理成速查表，给需要的人参考。
7.1 设备连接云平台失败怎么办
设备连不上云平台，我一般按这个顺序排查：先看网络通不通，在设备上ping一下服务器IP，不通就是网络配置问题；网络通的话，看端口通不通，MQTT默认1883端口，有些网络环境封了非标准端口；端口通了，看认证信息对不对，是不是三元组里的某个字段抄错了；认证没问题，就看ClientID是否重复，一个平台同时不允许两个相同ClientID的设备连接，经常会出现"上一个连接没断开，新连接一直上不来"的情况。
其中ClientID冲突这个是最隐蔽的，报错信息不一定直观。后来我养成了习惯，每个设备的ClientID或者MQTT Username里都嵌入设备唯一标识，排查起来快很多。
7.2 MQTT消息收到但内容解析不出来
消息能收到，说明链路是通的。解析不出来，八成是格式问题和编码问题。先确认设备端发的是不是合法的JSON，很多新手会拼出"{"temp":25.6}"但少了一个引号或者多了一个逗号。确认格式没问题后，再看字符串编码，有些传感器读出来的是字节流，没有正确转成UTF-8字符串。最后看字段类型，温度上报成了字符串"25.6"，后端期望的是浮点数25.6，类型不匹配在严格模式下解析也会失败。
7.3 设备频繁掉线，状态忽上忽下
设备频繁掉线，一般绕不开三个原因：信号弱、功耗不足、程序主动断开。信号弱就优化网络环境或者换通信方式；功耗不足要检查电源模块的输出能力，ESP32在Wi-Fi射频启动瞬间电流会冲到几百毫安，电源能力弱就直接掉电重启；程序主动断开就要检查代码里是不是有定时重连、内存溢出导致的异常重启。
内存溢出这块很多新手注意不到。ESP32虽然内存比STM32大不少，但如果你在循环里不断new对象、分配堆内存，最后必然死机重启。排查的时候可以在代码里打日志，看看重启前最后一条日志是什么，往往能定位到具体代码行。
7.4 阿里云物联网平台不支持新购怎么办
这个之前已经说过，这里再汇总一下解决办法。遇到公共实例不支持新购的情况，一是看平台文档是不是有新的实例类型或者产品线调整，按新版入口重新选购；二是考虑用开源方案自建——EMQX加一个简单的后端服务，功能完全可以平替；三是如果只是学习使用，本地装Mosquitto就够跑通整个流程，不一定非要上云。
我个人的态度是：应届生求职和课程设计尽量接触真实云平台，因为简历上写"用过阿里云IoT"确实比"本地搭过Mosquitto"好看；真正做产品，则要认真核算平台的设备接入费用、消息数量费用、存储费用，再决定用云平台还是自建。
8. 写在最后
想了很久要不要单独写个总结，后来觉得没必要。物联网技术架构这个东西，它不是一个看完就结束的知识点，而是你每做一个项目，都会对它多一层理解。我第一次做项目时觉得感知层最难，后来觉得网络层最头疼，再后来发现平台层的稳定性和应用层的体验才是项目成败的关键，一直到现在，我会更关注整个链路的数据质量和业务闭环。
最后给刚入门的朋友一个建议：不要试图把物联网的所有技术一次学完，也不要纠结自己在哪个层。你就是做一个小项目，一步步走完整个链路，从传感器到界面，哪怕它功能简单，只要整个链路是通的，你对物联网的理解就会上一个台阶。后面再遇到任何具体问题，你都知道它在架构里处于什么位置，也知道该去哪里找答案，这就够了。
