设备命令下发须设超时与重试：http.Client 需配置 Timeout、DialContext 和 ResponseHeaderTimeout；TCP/UDP 连接用 SetDeadline；重试采用指数退避（最多3次）；JSON 应 compact 且避免浮点尾零；并发需限流防资源耗尽。
设备命令下发必须处理超时和重试
Go 语言里用 net/http 或 net.Conn 发命令，不设超时等于默认阻塞到 TCP Keepalive 触发（可能几分钟），设备离线时整个 goroutine 就卡死。必须对每个下发动作显式控制生命周期。
-
http.Client要设置Timeout、Transport.DialContext和Transport.ResponseHeaderTimeout，三者缺一不可 - 自建 TCP/UDP 连接时，用
conn.SetDeadline()或conn.SetReadDeadline()+conn.SetWriteDeadline()，不能只设一个 - 重试建议用指数退避（如
time.Second * 1、time.Second * 2、time.Second * 4），最多 3 次；第 4 次失败直接标记设备异常，避免雪崩
JSON 命令体序列化要兼容设备端解析边界
很多嵌入式设备 JSON 解析器不支持浮点数尾随零、NaN、无穷大，也不接受多余空格或换行。Go 默认的 json.Marshal 输出可读但不“紧凑”，且会把 float64(0) 序列化成 0.0，某些固件直接拒收。
- 用
json.Compact压缩输出，去掉空格和换行 - 对 float 字段，提前转为整数（如果业务允许）：比如
int(v)替代v，或用fmt.Sprintf("%d", int(v))构造字符串字段 - 避免使用
json.RawMessage直接透传未校验 JSON，设备端解析失败时错误定位极难
并发下发多设备时需控制连接数和上下文取消
直接对几百台设备起几百个 goroutine 调 http.Post，很容易触发文件描述符耗尽（too many open files）或服务端限流。goroutine 泄漏风险也高——某个设备响应慢，对应 goroutine 就一直挂着。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用带缓冲的 channel 控制并发数，例如
sem := make(chan struct{}, 10)，每次发命令前sem ，完成后 <code><-sem - 所有 HTTP 请求必须带上
context.WithTimeout(ctx, 5*time.Second)，父 context 取消时自动中止全部请求 - 不要用
sync.WaitGroup等待全部完成后再返回，应边发边收结果，用select配合donechannel 实现“任意一个失败即退出”或“超时后返回已成功列表”
MQTT 场景下命令下发要区分 QoS 和 retain 行为
用 github.com/eclipse/paho.mqtt.golang 下发命令时，QoS 0 不保证到达，QoS 1 保证至少一次（可能重复），QoS 2 几乎不用（开销大）。retain 设为 true 会导致新上线设备立即收到旧命令，多数场景不该开启。
立即学习“go语言免费学习笔记（深入）”；
- 命令类 topic 建议固定格式如
cmd/{device_id}/req，响应 topic 为cmd/{device_id}/resp，避免通配符订阅引发干扰 - 下发前检查 client 是否已连接（
client.IsConnected() == true），未连接时先 wait 或 fallback 到 HTTP 回退通道 - 别依赖 MQTT 的 “last will” 做命令兜底——它只发一次且无法携带动态参数，真正可靠的做法是服务端记录 pending 命令，定期扫描超时未响应设备并重推
设备命令下发不是发完就完的事，真正的难点在“怎么确认它真的执行了”。状态上报、ACK 机制、服务端命令生命周期管理，这些都得和下发逻辑耦合设计，否则日志里全是“已发送”，现场却没人动过。
