用 paho.mqtt.golang 连接 MQTT 服务器失败主因是配置与网络环境不匹配：Docker 中 localhost 指向容器自身，需改用宿主机 IP 或 host.docker.internal；须同时启用 SetCleanSession(false) 和 SetAutoReconnect(true)；注意 EMQ X 默认用户可能被禁用、连接超时不宜过短、先 telnet 验证端口连通性。
怎么用 paho.mqtt.golang 连上 MQTT 服务器
连不上是最常见的卡点，不是代码写错，而是配置和网络环境没对齐。比如本地跑 EMQ X 时用 tcp://127.0.0.1:1883 没问题，但换成 Docker 容器后，localhost 在容器里指向自己，得换成宿主机 IP 或用 host.docker.internal（macOS/Windows）或 --network=host。
-
opts.SetCleanSession(false)和opts.SetAutoReconnect(true)要一起开，否则断网重连后订阅会丢失 - EMQ X 默认账号是
admin/public，但新版本可能禁用默认用户，得在 Dashboard 里手动开或建用户 - 连接超时别设太短——
opts.SetConnectTimeout(3*time.Second)在高延迟网络下容易假失败 - 如果报
connection refused，先telnet 127.0.0.1 1883看端口通不通，再确认 EMQ X 是否真在运行（docker ps查容器状态）
发布和订阅消息时，主题和 QoS 怎么选
主题名不是随便起的字符串，它决定了路由逻辑和权限控制粒度；QoS 不是越高越好，而是按场景权衡可靠性与开销。
- 设备上报状态建议用
devices/{device_id}/status，指令下发用devices/{device_id}/cmd，避免用泛化主题如all/cmd——后期没法做 ACL 隔离 - 传感器数据（温湿度、电量）用
QoS=0足够，丢了就丢，下个周期再报 - 开关类指令（如
turn_on）必须用QoS=1，否则设备可能根本没收到 - 别在
client.Publish()后直接token.Wait()做同步阻塞——高并发下会拖垮吞吐，应改用回调或 channel 监听token.Done()
为什么设备状态收不到，或者重复收到
这不是 Go 代码 bug，而是 MQTT 协议行为 + 客户端配置组合出来的“合理结果”。最常被忽略的是 SetCleanSession 和 Retained Message 的交互逻辑。
- 如果服务端发了保留消息（
Retain=true），而客户端用SetCleanSession(true)重连，每次都会再收一遍——这是协议规定的，不是重复 - 订阅时没传回调函数，或回调里 panic 了，会导致后续消息静默丢失（
paho默认不报错，只丢弃） - 多个 goroutine 并发调用
client.Subscribe()同一个 topic，可能触发重复订阅，造成双倍消息——应确保订阅只做一次，可用sync.Once控制 - 检查 EMQ X 的
mqtt.max_packet_size配置，如果设备发的 JSON 超过默认 256KB，会被静默截断，表现为“收一半”或解析失败
要不要加 Redis 缓存设备状态
加不加不取决于“看起来更专业”，而取决于你是否需要跨进程共享最新状态，以及能否承担缓存一致性风险。
立即学习“go语言免费学习笔记（深入）”；
- 单实例网关 + 内存 map 存状态完全够用，95% 的家庭场景不需要 Redis
- 一旦引入 Redis，就得处理「设备上线→更新 Redis→MQTT 发 online 消息→其他服务也监听该消息」的多源更新问题，容易出现状态不一致
- 如果真要用，别在
Subscribe回调里同步写 Redis（阻塞消息流），应把DeviceMsg推进本地 channel，另起 goroutine 异步刷库 -
redisClient.Set(ctx, "device:"+msg.DeviceID, msg, 10*time.Minute)这种写法没问题，但记得配好redis.WithTimeout，否则 Redis 挂了整个 MQTT 订阅回调就卡死
MQTT 的坑不在 Go 语法，而在协议语义和部署拓扑的耦合。比如你调通了本地测试，一上生产就出问题，八成是 TLS 配置、ACL 权限、Broker 负载限制或 DNS 解析这几个地方漏了查。
