遗嘱消息必须在 Connect 前通过 SetWill() 静态设置且仅一次，主题不可含通配符，QoS 为 1/2 保证送达，WillDelayInterval 仅在 CleanSession=false 时生效，payload 需预序列化、禁含敏感信息，测试须强制断连验证。
设置遗嘱消息必须在 Connect 前完成
遗嘱消息不是连接后补上的，而是在 ClientOptions 初始化阶段就固定下来的。一旦调用 client.Connect()，Broker 就只认这个预设的遗嘱，后续再改 SetWill() 也无效——这和很多初学者直觉相反。
-
SetWill()必须在mqtt.NewClient()之前或创建ClientOptions时调用，且只能设一次 - 遗嘱主题（
topic）不能含通配符（如+或#），否则 Broker 拒绝连接并返回CONNACK return code: 0x02 - QoS 设为
1或2才能保证送达，但会增加 Broker 负载；设为0则不保证，适合心跳离线通知这类低优先级场景
遗嘱延迟间隔（Will Delay Interval）要配合 Clean Session 使用
MQTT 5.0 引入了 WillDelayInterval，但它不是“延后发送”，而是“延后触发”：客户端断连后，Broker 会等这个时间，期间若客户端重连成功，就取消发送遗嘱。但这个机制只在 CleanSession=false（即启用持久会话）时才生效；如果设成 true，会话一销毁，遗嘱立刻发，延迟参数被忽略。
- 常见误操作：开了
WillDelayInterval=30，却没关SetCleanSession(true)，结果断连瞬间就收到遗嘱消息 - 延迟单位是秒，最大值由 Broker 决定（EMQX 默认上限 4294967295 秒，约 136 年；Mosquitto 默认不限，但建议别超 300 秒）
- Go 客户端需显式调用
opts.SetWill("topic/offline", []byte("offline"), 1, true)，第四个参数是retain，和延迟无关，别混淆
遗嘱消息内容不能动态生成
遗嘱是静态绑定的字节流，不是回调函数。你没法在断连那一刻才拼接时间戳、IP 或状态码——所有内容必须在 Connect 前就序列化好。想带上下文？得提前预估、编码进 payload。
- 例如想通知 “设备 ID-123 在 2026-04-01T12:07:00 离线”，就得在连接前算好这个字符串并传给
SetWill() - JSON 是常用选择，但注意长度限制：多数 Broker 对单条遗嘱 payload 限长 256KB，实际建议控制在 1KB 内，避免握手失败
- 不要把敏感信息（如 token、密钥）写进遗嘱，它可能被未授权订阅者收到，且无法加密（MQTT 遗嘱本身不支持 TLS 加密 payload）
测试遗嘱是否生效，别只靠 kill 进程
用 os.Exit(1) 或直接关 terminal 看似模拟断连，但 Go runtime 可能来不及触发 TCP FIN，Broker 判定为“网络闪断”而非“异常下线”，导致遗嘱不发。真正可靠的方式是主动关闭底层 socket 或拔网线。
立即学习“go语言免费学习笔记（深入）”；
- 开发期推荐：启动客户端后，用
netstat -an | grep :1883确认连接存在，再执行kill -9 <pid>（Linux/macOS）或任务管理器强制结束（Windows） - 更稳妥做法：在另一终端运行
tcpkill -i lo port 1883（需 root），直接切断 TCP 流 - 验证点：订阅
topic/offline后，不发Disconnect()就退出程序，看是否收到消息；如果收到，再试一次正常调用client.Disconnect(0)，确认这次没消息——这才是符合预期的行为
