直接用 golang.org/x/net/websocket 不行，因为 MQTT 协议具备独立的握手、心跳、QoS、遗嘱和会话管理机制，通用 WebSocket 库无法处理 CONNACK 解析、PINGREQ/PINGRESP 响应及 DISCONNECT 清理等关键逻辑，导致重连后消息丢失、重复投递或连接卡死。
为什么直接用 golang.org/x/net/websocket 不行
因为 MQTT 协议不是 WebSocket 的简单封装，它有独立的连接握手、心跳保活、QoS 分级、遗嘱消息和会话状态管理。用通用 WebSocket 库强行对接，会漏掉 CONNACK 解析、PINGREQ/PINGRESP 自动响应、DISCONNECT 清理会话等关键逻辑，最终表现为：重连后收不到旧订阅消息、重复投递、连接卡死在 Connecting 状态。
正确做法是基于成熟 MQTT 客户端库封装，首选 github.com/eclipse/paho.mqtt.golang（官方 Go 客户端），它原生支持 clean session、reconnect delay、自动重订阅，且底层已处理 TCP 断连检测与重试队列。
mqtt.NewClient 的配置陷阱
断线重连能力不靠手动轮询实现，而取决于客户端初始化时的选项。最常被忽略的是 KeepAlive 和 ConnectTimeout 的配合关系：如果 KeepAlive 设为 60 秒但 ConnectTimeout 只有 5 秒，网络抖动时会反复触发连接失败，却没机会发 PINGREQ 判断是否真断开。
-
KeepAlive: 30—— 建议设为 20–45 秒，太短增加服务端压力，太长导致断连发现延迟 -
ConnectTimeout: 10 * time.Second—— 必须大于 DNS 解析 + TCP 握手预期耗时 -
AutoReconnect: true—— 必开，否则断连后不会尝试恢复 -
MaxReconnectInterval: 60 * time.Second—— 防止指数退避过久，影响业务感知 -
OnConnectionLost回调里不要放阻塞操作（如同步 HTTP 请求），否则会卡住重连协程
如何安全地重订阅主题
MQTT 协议规定：clean session = true 时，重连后 broker 不保留订阅关系；clean session = false 时，broker 会代为维持，但客户端必须在重连成功后显式调用 Subscribe，否则本地回调注册丢失，收不到消息。
立即学习“go语言免费学习笔记（深入）”；
常见错误是把 Subscribe 写在初始化阶段，而没放在 OnConnect 回调里——这会导致首次连接正常，但断线重连后订阅失效。
opts.OnConnect = func(client mqtt.Client) {
token := client.Subscribe("sensor/+/temperature", 1, func(c mqtt.Client, msg mqtt.Message) {
fmt.Printf("recv: %s\n", msg.Payload())
})
token.Wait() // 必须 Wait 等待 SUBACK 返回，否则可能在 CONNECT 后立即发 PUB 导致乱序
}注意：token.Wait() 是同步阻塞调用，不能在高并发消息处理路径中滥用；生产环境建议加超时控制，例如 token.WaitTimeout(5 * time.Second)。
连接状态与错误日志怎么查
判断是否真“断线”，不能只看 client.IsConnected() 返回 false —— 它只反映最后一次连接状态，无法区分是主动断开还是网络中断。真正可靠的信号来自 OnConnectionLost 回调触发，且参数 err 非 nil。
容易被忽略的细节：
-
net.OpError类型错误（如dial tcp: i/o timeout）说明底层 TCP 连接失败，应触发重连 -
mqtt.ConnectionLost错误表示收到 broker 的DISCONNECT或心跳超时，此时需清理本地缓存 - 日志中出现
read tcp: use of closed network connection，大概率是 client 被Disconnect后又试图 Publish，需检查资源释放顺序
重连模块的复杂点不在连接本身，而在状态同步：比如重连期间积压的待发布消息要不要重发、QoS 1 消息的 PUBACK 是否丢失、离线期间的订阅变更如何合并——这些都得结合业务语义做取舍，没法靠通用库自动解决。
