MQTT QoS 0/1/2 由客户端库（如 paho.mqtt.golang）在 Publish() 调用时通过 qos 参数指定并自动实现语义保障；qos 必须为 0、1 或 2，传其他值将静默失败；服务端可降级 QoS 且不通知客户端；QoS 2 易因 Broker 不支持或网络问题导致 token.Wait() 卡住。
MQTT QoS 0/1/2 在 golang 客户端中由谁控制？
QoS 等级不是在 Go 代码里“手动实现”的逻辑，而是由 MQTT 客户端库（如 github.com/eclipse/paho.mqtt.golang）在调用 client.Publish() 时通过参数指定，并由底层协议栈自动处理重传、确认、去重等行为。你只需明确传入期望的 QoS 值，库会按标准完成对应语义保障。
client.Publish() 的 qos 参数怎么设才有效？
调用 Publish() 时第三个参数是 qos byte，必须为 0、1 或 2；传其他值（比如 3）会导致发布失败且无明确错误提示，只返回 nil 错误但消息不发出——这是最常踩的坑。
示例：
token := client.Publish("topic/test", 1, false, "hello") // QoS 1
if token.WaitTimeout(2*time.Second) && token.Error() != nil {
log.Println("publish failed:", token.Error())
}
-
qos=0：最多一次，不保证送达，不阻塞，无确认流程 -
qos=1：至少一次，服务端发PUBACK，客户端需等待 token 完成才能确保被接收（否则可能重复） -
qos=2：恰好一次，依赖PUBREC/PUBREL/PUBCOMP三步，开销最大，token.Wait()必须调用，否则无法感知是否真正完成
QoS 协商失败会发生什么？
MQTT 连接时，客户端在 CONNECT 包中声明支持的 QoS，但最终每条消息的 QoS 是“以服务端为准”：如果服务端不支持某 QoS（例如禁用 QoS 2），它会把收到的 QoS 2 消息降级为自身允许的最高级别（通常是 QoS 1），且不会通知客户端。你无法从 token.Error() 中捕获这种降级。
验证方式只有两端日志比对或抓包看实际 PUBLISH 固定头中的 QoS 字段。生产环境建议统一约定服务端允许的 QoS 范围，并在连接后主动查询（部分 Broker 支持 $SYS 主题获取配置）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
为什么 qos=2 在 Go 客户端容易卡住或超时？
因为 qos=2 要求完整四步握手，任意环节丢包或延迟都会让 token.Wait() 阻塞。常见原因包括：
- Broker 不支持 QoS 2，静默降级但客户端仍按 QoS 2 流程等待
PUBCOMP（永远等不到） - 网络不稳定导致
PUBREL丢失，服务端不发PUBCOMP - 客户端未设置足够长的
token.WaitTimeout()，默认 30 秒可能不够 - 使用了共享订阅（
$share/...）且 Broker 实现有缺陷，QoS 2 状态不同步
调试时务必开启客户端 debug 日志：mqtt.DEBUG = log.New(os.Stdout, "[DEBUG] ", 0)，观察是否发出 PUBREC 后迟迟没有 PUBREL 或 PUBCOMP。
QoS 看似只是个数字参数，但它背后绑定了网络模型、Broker 能力、超时策略和错误恢复逻辑——改一个 1 成 2，可能要同步调整重试机制、监控指标和日志采样方式。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
