CoAP 还是 MQTT：两种设备协议的选型依据
两者都很常见，但解决的问题不同。本文从通信模型、网络条件、功耗和生态四个角度说明各自适用的场景，以及混用时要注意什么。
- MQTT 是发布订阅加长连接，CoAP 是请求响应且无连接，模型不同而非轻重之分。
- CoAP 的观察机制可以实现推送，但语义围绕资源，与主题树是两种组织方式。
- 电池供电、低占空比场景 CoAP 通常更省电；需要随时接收下行则 MQTT 更合适。
- CoAP 也可运行在 TCP 与 WebSocket 上，用于只允许 TCP 的网络环境。
- 混用两种协议时，必须保证两条路径写入的物模型数据结构一致。
设备协议选型的讨论常常停留在「哪个更轻」。两者都很轻，真正的差别在通信模型：MQTT 是发布订阅，设备与平台之间维持一条长连接；CoAP 是请求响应，形态更接近 HTTP，只是跑在 UDP 上并做了大幅精简。
通信模型决定了适用场景
发布订阅天然适合「多个消费方关心同一批数据」的场景：一台设备上报，平台、告警服务、数据分析各自订阅，设备不需要知道有谁在听。请求响应适合「明确向某个资源取数或下发」的场景：读取某个传感器的当前值、修改某项配置。
CoAP 并非没有推送能力。协议定义了观察机制，客户端可以注册对某个资源的观察，资源变化时服务端主动推送更新。但它的语义仍然是围绕资源的，与 MQTT 的主题树是两种组织方式。
网络条件
- MQTT 依赖长连接，连接保持本身有心跳开销；网络频繁切换或 NAT 超时激进的环境下，重连会比较频繁；
- CoAP 基于 UDP，无连接，设备可以醒来发一包就睡，不需要维持状态，更适合极低占空比的场景；
- 在丢包率高的网络上，TCP 的拥塞控制有时反而不利，而 CoAP 的轻量重传机制更可控；
- CoAP 也可以跑在 TCP 和 WebSocket 上，用于需要穿越只允许 TCP 的中间设备的场合。
功耗
对电池供电、每天只醒来几次的设备，CoAP 通常更省：没有连接建立与保持的开销，一次交互就是一两个报文。对常供电、需要随时接收下行命令的设备，MQTT 的长连接反而更合适 —— 用 CoAP 实现同样的实时下发，要么设备常驻监听，要么引入额外的唤醒机制。
生态与现实因素
MQTT 在国内云平台上的支持更普遍，文档、SDK 和运维工具更成熟，团队熟悉度通常也更高。CoAP 在 NB-IoT 场景和部分行业标准体系里更常见。如果项目没有特别的功耗或网络约束，生态成熟度本身就是一个合理的选型理由 —— 它直接影响开发周期和后续排障效率。
混用的情况
同一个平台接入两类设备并不少见：常供电的网关走 MQTT，电池供电的终端走 CoAP 经网关转发。这种结构下要特别注意物模型的一致性 —— 两条接入路径最终写入的数据结构必须相同，否则下游的规则引擎和报表就要分别处理两套格式。相关的物模型设计可以参考我们在物联网平台解决方案中的做法。两种协议的接入实现差异不小，排期时建议参考平台与系统开发中对接入层工作量的估算方式。
常见问题
CoAP 和 MQTT 哪个更适合 NB-IoT？
通常是 CoAP。NB-IoT 设备多为电池供电、低频上报，CoAP 无需维持连接，一次交互只有一两个报文，功耗和流量都更低。但具体还要看运营商与模组支持情况，以及平台侧是否已有成熟的 CoAP 接入能力。
一个平台能同时支持两种协议吗？
可以，也很常见。关键是在接入层之后统一成同一套物模型，让规则引擎、存储和展示只面对一种数据结构。如果两条路径一直分开到业务层，维护成本会成倍增加。
CoAP 能做实时下发命令吗？
可以通过观察机制实现，但要求设备保持可达。对于长时间休眠的设备，更常见的做法是设备主动轮询，或者由网络侧的唤醒机制触发，这都会带来时延，需要在需求阶段明确可接受的下发时延范围。