绝大多数嵌入式C++项目应使用libcoap而非手写CoAP栈，因其已完整实现RFC 7252细节（如可变Token、delta排序Option、Block2溢出防护），静态链接仅占约12KB Flash和1.8KB RAM，且避免重传逻辑、Observe维护等易错问题。
用 libcoap 还是自己手写 CoAP 栈？
绝大多数嵌入式 C++ 项目不该自己实现 CoAP 报文编解码和重传逻辑——RFC 7252 的细节太多，比如 Token 长度可变、Option 编码需按 delta 排序、Block2 分块的 offset 计算容易溢出。libcoap 是 IETF 官方推荐的 C 实现，C++ 项目可以直接链接使用，它已处理好 UDP socket 复用、重传定时器、CON/NON 消息区分、Observe 序列号维护等关键逻辑。
除非你的 MCU RAM 小于 8KB 或 Flash 不足 64KB（比如某些 Cortex-M0+ 芯片），否则不建议砍掉 libcoap 改用裸 UDP + 手动拼包。实测在 STM32L4 上，启用基本功能（GET/POST + 确认机制）的 libcoap 静态链接后仅占约 12KB Flash 和 1.8KB RAM。
常见错误现象：sendto() returns -1 却没检查 errno；或把 coap_context_t* 当全局变量反复初始化导致内存泄漏；又或者在中断服务中直接调用 coap_send() 引发不可重入问题。
如何让 CoAP 请求真正“低功耗”？
CoAP over UDP 本身不保活，但低功耗节点必须控制射频模块的开启时长。关键不是协议栈本身，而是调度策略：
立即学习“C++免费学习笔记（深入）”；
- 所有网络操作必须在单次唤醒周期内完成：MCU 唤醒 → 初始化 radio → 构造并发送 CoAP 包 → 启动超时定时器（通常 2~3 秒）→ 等待响应或超时 → 关闭 radio → 进入深度休眠
- 避免在
coap_run_once()中阻塞等待：它只是轮询一次 socket 和定时器，应配合非阻塞 socket 使用；若用阻塞 socket，务必设SO_RCVTIMEO，否则可能卡死 - 不要为每个传感器读数都发一个 CON 包：合并多个字段进一个 CBOR payload，用单次 POST 提交；状态变化不频繁时，改用 NON 类型消息（无重传），靠业务层容忍丢包
- 禁用
Observe功能除非真需要实时推送：它会维持 server 端观察者列表，对电池设备来说，被动接收通知比主动查询更耗电
Token 和 Message ID 怎么管理才不出错？
Token 不是 session ID，也不是加密密钥，它只是客户端用于匹配响应的“回执编号”。libcoap 默认生成 2 字节随机 Token，但在资源极紧的节点上，可以复用固定值（如 0x01）——只要确保同一时间只存在一个未完成请求即可。Message ID 则必须严格递增，不能重复，否则 server 可能将新请求误判为重传而丢弃。
容易踩的坑：
- 在休眠前没清空 pending request 队列，唤醒后旧
Message ID被复用，server 返回 RST - 用
uint16_t存 Message ID 却不做溢出检测，ID 回绕后与历史请求冲突 - 把
Token设为全局常量还同时发多个请求，导致收到 ACK 时无法区分对应哪个请求
建议做法：用一个 static uint16_t s_next_mid = 0; 全局计数器，每次调用 coap_new_request() 前原子加一；Token 可设为 static uint8_t s_token = 0; 并随每次请求递增（8-bit 足够覆盖单次唤醒内的全部请求）。
CBOR 编码比 JSON 省多少？为什么必须用？
在温湿度+电量三字段上报场景中，JSON 编码典型长度为 {"t":23.5,"h":65,"v":3.28} → 32 字节；同等语义的 CBOR（使用整数键+半字节浮点压缩）可压到 12~14 字节。这不只是“省一点”，而是直接影响空中传输时间：在 50kbps 的 NB-IoT 模块上，32 字节需约 5.1ms 射频开启时间，14 字节仅需 2.2ms —— 多出来的 3ms 全部是额外功耗。
libcoap 本身不带 CBOR 支持，需集成 QCBOR 或 tinycbor。注意：coap_set_payload() 只接受 raw bytes，你得自己用 CBOR 库序列化后再传进去；反序列化解析响应也得手动调用 CBOR 解码器，libcoap 不会自动识别 content-format。
别忽略 Content-Format option：必须显式设置为 100（CBOR）或 50（JSON），否则 server 默认按 text/plain 处理，解析失败返回 4.06 Not Acceptable。
最易被忽略的一点：CoAP 的“低开销”不只在报文大小，更在**行为确定性**。HTTP/TCP 的连接建立、TLS 握手、拥塞退避全是黑盒；而 CoAP 的每一次重传间隔、最大重试次数、是否分块，全由你代码控制。这意味着你必须亲手校准这些参数——比如在 LoRaWAN 下把重传间隔从默认的 2 秒拉长到 5 秒，否则连续重传会触发网关限速。
