coap客户端连不上服务器需检查gcoap监听地址（必须为":5683"，不可绑定localhost）、目标ip一致性、防火墙udp 5683端口、启用重传机制（gcoap.withretransmit）、避免payload内存复用、路径注册不带尾斜杠。
CoAP 客户端连不上服务器？先检查 gcoap 的监听地址和端口
Go 原生不支持 CoAP，得靠第三方库，目前最稳定的是 github.com/plgd-dev/go-coap（原 gcoap）。它默认监听 :5683，但如果你用 net.ListenUDP 手动启服务，却写成 ":5684" 或 "127.0.0.1:5683"，客户端就收不到响应——CoAP 要求广播/多播兼容性，绑定 localhost 会丢包。
- 服务端启动必须用
":5683"（空主机名），不能写死127.0.0.1或::1 - 客户端发请求时，
net.DialUDP的目标地址要和服务器实际暴露的 IP 一致；内网设备常用192.168.x.x:5683，别误填成localhost:5683 - 防火墙常拦截 UDP 5683 端口，Linux 用
sudo ufw status确认，macOS 检查“防火墙选项”里是否允许 UDP
POST 请求 payload 总是被截断？注意 Message.Payload 的字节切片所有权
CoAP 消息体不是字符串，是 []byte。很多新手直接传 string 转换结果：[]byte("hello")，看似没问题，但若这个切片后续被复用（比如在 handler 里存进 map 或传给 goroutine），可能因底层内存重用导致内容突变——gcoap 内部会复用 buffer。
- 安全做法：用
append([]byte(nil), data...)显式分配新底层数组 - 如果 payload 来自 JSON 编码，别直接传
json.Marshal(v)返回值；应拷贝一次：payload := append([]byte(nil), b...) - GET 请求无 payload，但某些设备固件会把查询参数塞进 URI 后面（如
/sensors?mode=on），此时不要往Message.Payload写东西，否则触发 4.00 Bad Request
为什么 gcoap.Client.Do() 一直 timeout，但 tcpdump 显示包已发出？
CoAP 是基于 UDP 的轻量协议，没有 TCP 那样的连接状态。gcoap.Client.Do() 默认只发一次，超时后直接返回错误，不会自动重传。而真实物联网环境丢包率高，尤其在 WiFi 信号弱或 NB-IoT 场景下，单次发送几乎必失败。
- 必须手动启用重传机制：创建 client 时传入
gcoap.WithRetransmit(3)（最多重试 3 次） - 重传间隔不是固定值，
gcoap用指数退避，默认首次 2 秒，第二次 4 秒……总耗时可能超你设的context.WithTimeout - 别在循环里反复 new Client；复用同一个
*gcoap.Client实例，否则 UDP conn 可能被系统限制（too many open files）
资源路径带斜杠就 4.04？gcoap.ServeMux 对注册路径很敏感
gcoap.ServeMux 不像 HTTP mux 那样自动处理尾部斜杠。注册 /light 和访问 /light/ 是两个不同路径，后者直接 404。更麻烦的是，有些设备（比如 Zephyr SDK 的 CoAP server）会自动补斜杠，而 Go 客户端没做标准化处理。
- 注册 handler 时统一用无尾斜杠形式：
mux.Handle("/light", lightHandler)，别写/light/ - 客户端构造 URI 时，用
url.JoinPath("coap://192.168.1.100", "light")替代字符串拼接，避免多出 / - 调试时用
coap-client -m get coap://[::1]/light对比行为，确认是服务端路由问题还是客户端拼写问题
CoAP 的“简单”背后全是 UDP 的不可靠细节：重传策略、块传输（Block-Wise）分片、观察模式（Observe）的序列维护……这些在 gcoap 里都得手动开关、手动校验，没 HTTP 那种开箱即用的错觉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
