CoAP客户端连不上服务端，八成因监听地址未设为":5683"或误用localhost；须用空主机名绑定UDP端口，启用重传机制，避免payload内存复用，路径注册不带尾斜杠。
CoAP 客户端连不上服务端？八成是 ":5683" 没写对，或者目标地址用了 localhost。
gcoap.ListenAndServe 为什么监听失败或收不到请求
Go 原生不支持 CoAP，必须用第三方库；当前最稳定的是 github.com/plgd-dev/go-coap（原 gcoap）。它默认要求服务端监听地址为 ":5683" —— 注意：空主机名，不能写成 "127.0.0.1:5683" 或 "::1:5683"。
原因很直接：CoAP 设计上要兼容广播和多播，绑定具体 IP 会绕过内核的 UDP 组播/任播路由逻辑，导致客户端发包后服务端根本收不到。哪怕你只在本地测试，也得用 ":5683"。
- ✅ 正确：
coap.ListenAndServe("udp", ":5683", mux) - ❌ 错误：
coap.ListenAndServe("udp", "127.0.0.1:5683", mux)、coap.ListenAndServe("udp", "[::1]:5683", mux) - 防火墙常拦截 UDP 5683，Linux 下检查：
sudo ufw status；macOS 确认“系统设置 > 防火墙 > 防火墙选项”中允许 UDP 入站
gcoap.Client.Do() 一直 timeout，但 tcpdump 显示包已发出
CoAP 基于 UDP，gcoap.Client.Do() 默认只发一次，不重传。真实物联网链路丢包率高，单次发送基本必超时。
立即学习“go语言免费学习笔记（深入）”；
必须显式启用重传机制：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
gcoap.WithRetransmit(3)设置最多重试 3 次（首次间隔约 2 秒，后续指数退避） - 注意：总耗时可能远超你
context.WithTimeout设的值，比如设了 3 秒，实际等满 14 秒才返回错误 - 别在循环里反复
new(gcoap.Client)—— 每个 Client 占一个 UDP socket，容易触发too many open files - 复用同一个
*gcoap.Client实例，它本身是 goroutine-safe 的
payload 被截断或内容突变
Message.Payload 是 []byte，不是字符串。很多新手直接传 []byte("hello") 或 json.Marshal(v) 返回值，结果 handler 里一存 map / 一传 goroutine，内容就变了。
这是因为 gcoap 内部复用底层 buffer，原始切片底层数组被覆盖。
- 安全做法：用
append([]byte(nil), data...)强制分配新底层数组 - GET 请求不要往
Message.Payload写任何东西，否则设备固件可能直接返回4.00 Bad Request（查询参数应拼在 URI 后，如/sensors?mode=on） - 注册路径时注意尾斜杠：
mux.Handle("/light", handler)和访问/light/是两个不同路径，后者直接404
资源路径注册和观察模式怎么写才不踩坑
gcoap.ServeMux 不做路径归一化，/a 和 /a/ 视为完全不同的资源。观察（Observe）模式更麻烦：它依赖客户端和服务端共同维护序列号和重传状态，库不自动帮你续订。
如果你需要长期观察某个传感器值：
- 别依赖单次
client.Observe()调用；得自己定时重发Observe=0的 GET，并处理4.04或连接中断 - 块传输（Block-wise Transfer）需手动解析
Block2Option 并拼接 payload，gcoap不自动聚合 - 生产环境务必加
WithDTLS()或走反向代理套 TLS，裸 UDP 传敏感数据等于广播
最易忽略的一点：CoAP 的“简单”是协议层的，工程落地时，重传策略、buffer 生命周期、路径匹配精度、观察续订逻辑，全得自己兜底。没这些细节意识，跑通 demo 很快，上线后掉包、panic、404 泛滥就很难排查。
