IoT 通信协议怎么选：HTTP / MQTT / WebSocket / ESP-NOW / BLE 对比

板子终于连上 WiFi 了，传感器也读到了数。下一步问题来了：这个数据怎么发出去？

打开教程，满屏是 HTTP、MQTT、WebSocket、ESP-NOW、BLE 这一堆名词。每个看起来都能"传数据"，每个底下都有人说"这个最好用"。但它们到底差在哪、你的项目该用哪个，没人一句话讲清楚。

结果就是：照着第一篇教程抄了 HTTP，做出来发现手机收到数据要等三五秒；或者上来就学 MQTT，被 broker、topic、QoS 一堆概念劝退，其实你的需求只是偶尔上传一次温度。

选错通信方式，代价不是"跑不起来"，而是"跑起来了但很难受"——费电、卡顿、白写一堆代码。这篇把五种最常见的通信方式逐个讲清楚：它擅长什么、不擅长什么、什么场景该选它。看完你能对着自己的项目直接选。

先把五个角色认清楚

它们不是互相替代的关系，更像工具箱里五把不同的工具。先一句话给每个定个性：

• HTTP：一问一答。设备主动发一次请求，服务器回一次，完事就断。
• MQTT：广播站。设备把消息扔给一个中转站（broker），谁订阅了谁收到，多设备解耦。
• WebSocket：电话热线。建立一条长连接，双方随时能互相说话，不用反复拨号。
• ESP-NOW：对讲机。两块 ESP 板子直接喊话，不需要路由器，不需要 WiFi 网络。
• BLE：蓝牙近场。手机走到设备旁边，直接连上配置或读数据，超省电。

下面逐个展开。

① HTTP：偶尔上传、调个 API，简单优先

HTTP 就是浏览器访问网页用的那套协议。在 IoT 里，它的典型用法是设备每隔几分钟主动"上报"一次：发一个 POST 请求把温湿度传到服务器，或者 GET 一下天气接口拿数据回来显示。

适合什么：低频上传、调用现成的 Web API（天气、汇率、时间）、对接已有的后端接口。它的最大优点是简单和通用——几乎所有云服务都有 HTTP 接口，ESP32 的库也最成熟，新手最容易跑通。

不适合什么：实时和高频。HTTP 是"一次性"的，设备想知道服务器有没有新指令，只能不停地去问（轮询）。你要做远程开关灯，用 HTTP 就得让设备每秒问一次"现在该开灯了吗"——费电、费流量、还有延迟。

一句话：偶尔发数据、逻辑简单，HTTP 够用且省心。展开看 HTTP 怎么用。

② MQTT：多设备、要上云、远程控制的标配

MQTT 是专门为 IoT 设计的。它的核心是"发布/订阅"：设备不直接和谁通信，而是把消息发到一个叫 broker 的中转站，标上一个 topic（比如 home/livingroom/temp）；任何关心这个 topic 的客户端订阅一下，就能实时收到。

适合什么：设备多、需要解耦、要远程控制、要上云。它解决的正是 HTTP 的痛点——服务器有新指令，直接推给设备，设备不用轮询。十个传感器、三个手机 App、一个后端，全挂在一个 broker 上，互相不用知道对方存在。这是智能家居、远程监控的事实标准。巴法云这类平台就是基于 MQTT 做的，参见 用巴法云上云。

代价是什么：你得有一个 broker。要么用公共/云服务（比如 EMQX、巴法云），要么自己搭一个。比 HTTP 多一层概念（topic、QoS 等级、保留消息），上手成本略高。

一句话：只要涉及"多个东西要互通"或"远程控制"，优先 MQTT。展开看 MQTT 怎么用。

③ WebSocket：网页实时仪表盘、AI 语音流

WebSocket 在一条 TCP 连接上做"全双工"——连接建好后，浏览器和服务器谁都能随时主动发消息，不用像 HTTP 那样一问一答。它和网页是天生一对。

适合什么：网页端的实时交互。你想做一个浏览器打开就能看到设备实时曲线的仪表盘，数据每秒刷新；或者做 AI 语音硬件，音频要一段一段流式地传给服务器、识别结果实时返回——这种"持续的双向数据流"正是 WebSocket 的主场。做 AI 语音项目的选型可以看 AI 语音硬件清单。

不适合什么：纯设备间通信、低频上报。如果没有网页、不需要这么强的实时性，WebSocket 反而是杀鸡用牛刀，MQTT 或 HTTP 更合适。

一句话：要"网页 + 实时"或"AI 语音流"，用 WebSocket。展开看 WebSocket 怎么用。

④ ESP-NOW：两块板直连、低延迟、省电

前面三个都离不开 WiFi 网络和 IP。ESP-NOW 是乐鑫自家的协议，让两块（或多块）ESP 板子不连路由器、不接入任何 WiFi 网络，靠 MAC 地址直接喊话。

适合什么：设备到设备的直连。比如一个遥控器控制小车、一个按钮触发另一块板上的继电器、几个传感器节点把数据汇到一个节点。它延迟极低（毫秒级），收发都不用建立连接，特别省电——非常适合电池供电、要求快速响应的场景。

局限是什么：它只在 ESP 设备之间用，数据进不了互联网。手机收不到，云端也看不到。它解决的是"近距离、设备间"的问题，不解决"上云"。

一句话：两块板子要直接通信、要快要省电、不需要联网，选 ESP-NOW。展开看 ESP-NOW 怎么用。

⑤ BLE：手机就近直连、配置、省电

BLE（低功耗蓝牙）的典型画面是：手机走到设备旁，打开 App，蓝牙列表里点一下就连上了，然后配置 WiFi 密码或者读一下数据。

适合什么：手机和设备的就近交互。最常见的用途是"配网"——设备第一次没有 WiFi，没法用 HTTP/MQTT，这时用 BLE 让手机把 WiFi 账号密码传给它。还有手环、温度计这类需要手机就近读数、又要电池撑很久的设备，BLE 的超低功耗是关键。

局限是什么：距离短（一般十米内）、需要主动配对、传输量小。它不是用来持续传大数据或者远程通信的。

一句话：手机就近配置或读数、要省电，选 BLE。展开看 BLE 怎么用。

一张表把它们摆一起

协议	要路由/WiFi 网吗	实时性	功耗	要服务器吗	典型场景
HTTP	要	弱（一问一答）	中	要后端接口	偶尔上传、调天气 API
MQTT	要	强（推送）	中	要 broker	多设备、上云、远程控制
WebSocket	要	很强（全双工）	中高	要服务端	网页实时仪表盘、AI 语音流
ESP-NOW	不要	很强（毫秒级）	低	不要	两块板直连、遥控、传感器汇聚
BLE	不要	中	极低	不要	手机就近配网、读数

看这张表的关键三列：要不要联网、要不要服务器、实时性。这三个一定，方向基本就定了。

决策路径：照着选

不想读完五段，直接对号入座：

• 数据要上云、要远程控制、设备不止一个 → MQTT。这是覆盖面最广的选择，纠结的话默认选它。
• 要在网页上看实时数据，或者做 AI 语音流 → WebSocket。
• 两块板子要直接通信、要快要省电、不联网 → ESP-NOW。
• 手机走过去配置设备 / 第一次配网 → BLE。
• 只是偶尔传一次数据、调个现成 API、图省事 → HTTP。

记住一个简化版口诀：上云用 MQTT，网页实时用 WebSocket，板间直连用 ESP-NOW，手机近场用 BLE，简单上传用 HTTP。

它们能组合用——而且经常组合

新手常以为只能选一个，其实成熟项目几乎都是混搭。最经典的一套：

ESP-NOW 节点 + 网关 MQTT 上云。 屋里布了五个电池供电的传感器节点，它们之间用 ESP-NOW（省电、不占 WiFi 名额）把数据汇到一个常供电的"网关"板子；网关一块连着 WiFi、用 MQTT 把汇总数据推到云端。这样既享受了 ESP-NOW 的省电，又拿到了 MQTT 的上云能力。这套网关模式怎么搭，看 搭一个网关。

再比如：BLE 配网 + MQTT 工作。 设备出厂没 WiFi，第一次用手机走 BLE 把网络配好，配好之后就切到 MQTT 正常上云——两个协议各干各擅长的活。

所以别纠结"二选一"，先看每一段通信的需求，分段选最合适的。

选错的代价：两个真实的坑

坑一：用 HTTP 轮询硬做实时。 想做远程开关灯，又只会 HTTP，于是让设备每秒发一次请求问"该开灯了吗"。后果：设备一直在收发、根本睡不着，电池几小时就空；流量蹭蹭涨；点了开关还要等下一次轮询才生效。这种场景就该用 MQTT 的推送，服务器一有指令立刻送到，设备平时可以休眠。

坑二：裸 MQTT 不加密就上公网。 MQTT 默认走 1883 端口、明文传输。你图快直接用，账号密码和数据全在网上裸奔，别人抓包就能看、甚至能往你 broker 发指令控制你家设备。但凡数据出了局域网，就得上 TLS 加密（8883 端口）、设好账号权限。怎么加固看 通信安全。

常见误区

误区	实际情况
"MQTT 比 HTTP 高级，所以都用 MQTT"	偶尔传一次数据、不需要推送，HTTP 更简单。别为用不上的能力买单
"ESP-NOW 能直连，那干脆全用它"	ESP-NOW 进不了互联网，只能 ESP 设备间用。要上云还得配 MQTT
"WebSocket 实时性最好，所以最优"	没有网页、不需要持续双向流，它只是徒增复杂度
"BLE 就是用来传大数据的蓝牙"	BLE 是低功耗、小数据、近距离，传大文件不是它的活
"选一个就够了"	成熟项目常组合：ESP-NOW 汇聚 + MQTT 上云是标配
"MQTT/WebSocket 默认就安全"	默认明文。出了局域网必须加 TLS，否则等于裸奔

动手挑战

拿你手上正在做（或想做）的项目，回答三个问题，把通信方式选出来：

1. 数据最终要去哪？ 只在两块板子之间 → ESP-NOW；要进手机 → BLE 或上云；要远程访问 / 多设备 → 上云走 MQTT。
2. 要不要实时双向？ 网页要实时刷 / AI 语音流 → WebSocket；要远程下指令 → MQTT 推送；只是偶尔上报 → HTTP。
3. 要不要省电、要不要联网？ 电池供电 + 不联网 → ESP-NOW / BLE；常供电 + 要上云 → MQTT / WebSocket。

举个例子写一句话答案："我做电池供电的土壤湿度传感器，多个节点要汇总上云——节点间用 ESP-NOW 省电，网关用 MQTT 上云。" 把你的答案也这样写出来，理由写清楚，下一步照着对应的 guide 去实现就行。

小结

五种通信方式没有谁绝对最好，只有谁更适合你这一段需求：HTTP 简单、MQTT 上云、WebSocket 网页实时、ESP-NOW 板间直连、BLE 手机近场。先用"要不要联网 / 要不要服务器 / 要不要实时"三问定方向，再看是不是要组合——ESP-NOW 汇聚 + 网关 MQTT 上云是覆盖最多场景的一套打法。

选好之后，回到 学习路线图 看你处在哪一站，挑对应的 guide 把它真正写出来。能把数据稳稳发出去，你的设备才算真正"活"了。