必须加 token.Wait() 否则消息会丢包；订阅需传非 nil handler 否则消息被丢弃；qos=0 消息可能因 broker 配置“假丢包”；Disconnect 应显式调用而非 defer。
connect() 调用后不加 token.Wait() 就发消息？会丢包
MQTT 客户端连接是异步的，client.Connect() 返回的是一个 token，不代表连接已就绪。如果跳过 token.Wait() 直接调用 publish() 或 subscribe()，大概率触发 panic: client is not connected 或静默失败——消息根本没发出去。
-
token.Wait()是阻塞等待连接完成，必须加；但别在主线程死等，建议设超时（如token.WaitTimeout(5 * time.Second)） - 检查错误不能只看
token.Error() != nil，还要确认token.Wait()返回值为true，否则可能是超时未完成 - 生产环境应配合重连逻辑，比如用
opts.SetAutoReconnect(true)+ 自定义OnConnectionLost回调
订阅时传 nil 作 handler？收不到任何消息
client.Subscribe(topic, qos, nil) 看似简洁，实则埋雷：MQTT 库不会帮你注册默认回调，nil 表示“不处理收到的消息”，哪怕订阅成功，Message 对象也会被直接丢弃。
- 必须显式传入
MessageHandler函数，哪怕只是打印日志：func(client MQTT.Client, msg MQTT.Message) { fmt.Println(string(msg.Payload())) } - handler 内部不要做耗时操作（如 HTTP 请求、数据库写入），否则会阻塞整个 MQTT 事件循环；应把消息推到 Go channel 后由 goroutine 异步处理
- 注意闭包捕获变量问题：循环中订阅多个 topic 时，别在匿名函数里直接用循环变量
topic，要用局部副本
发布时 qos=0 但消息还是没到？检查 broker 是否启用了 retain 或 clean session
client.Publish(topic, 0, false, payload) 看似简单，但实际送达依赖 broker 行为。常见假“丢包”其实是 broker 配置或客户端状态导致：
-
retain=false时，若订阅者晚于发布者上线，且 broker 清除了历史消息（clean session=true），那这条 qos=0 消息就真的消失了 - 测试阶段建议先用公共 broker（如
tcp://broker.hivemq.com:1883）排除本地配置问题；生产务必自建或托管 broker（如 EMQX），并确认其allow_anonymous、max_connections等参数合理 - qos=0 不保证送达，但能保证最低开销；若业务需要可靠性，要么升 qos=1（注意 broker 必须支持），要么在应用层加 ACK 机制（如发布后等待订阅端回一条确认 topic）
为什么 client.Disconnect(250) 放 defer 里反而断连失败？
defer client.Disconnect(250) 看似优雅，但 Go 的 defer 是在函数 return 前执行，而 main 函数退出太快时，Disconnect() 可能根本来不及发完 FIN 包就被 OS 强制回收连接。
- 正确做法是显式控制生命周期：用
os.Signal捕获os.Interrupt或syscall.SIGTERM，收到信号后再调client.Disconnect(250)并os.Exit(0) -
250单位是毫秒，不是超时而是“最多等 250ms 让 broker 收到断连通知”，太短可能无效；一般设 1000–5000 更稳妥 - 如果程序要长期运行（如服务进程），
Disconnect()反而不该调用——让连接保持活跃，靠 keepalive 和自动重连更可靠
真正难的不是连上 broker，而是理解每条 token.Wait()、每个 nil handler、每次 Disconnect() 背后，MQTT 协议状态机和 Go 运行时调度之间那层微妙的时序关系。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
