生产环境应选用gobit而非mbgo解析Modbus TCP协议；gobit支持并发、连接池、自动事务ID及显式slaveID，而mbgo并发读写会panic或乱码，且超时、重试、字节序、粘包等问题需手动严谨处理。
生产环境解析设备协议，别碰 mbgo——它在多 goroutine 轮询 PLC 时会 panic 或返回乱码；gobit 才是能扛住真实工控场景的选择。
Modbus TCP 并发读写必须用 gobit
设备协议里 Modbus TCP 最常见，但 mbgo 的 RTUClient 和 TCPClient 都不支持并发调用 ReadHoldingRegisters。多个 goroutine 同时读，轻则数据错位，重则直接 panic。而 gobit 基于标准 ADU 封装，连接由 net.Conn 管理，天然支持并发 + 连接池 + 自动事务 ID 递增。
-
gobit的client.ReadHoldingRegisters(ctx, 1, 0, 10)显式传slaveID，多设备混连不串 -
mbgo初始化时绑定slaveID，后续所有读写都复用它，一换设备就得 new client，极易出错 - 别信 “
mbgo.SetTimeout()” —— 它只控制 write 超时，read 仍可能卡死数分钟
超时和重试必须手动加，库不会替你兜底
Modbus 协议本身没有心跳、重连或请求级超时机制。gobit.NewClient(conn) 默认用无超时的 net.Dial，网络抖动或设备断电后，ReadCoils 会阻塞整个 goroutine。
- 建立连接时用
net.DialTimeout("tcp", "192.168.1.10:502", 3*time.Second) - 每次请求套
context.WithTimeout(ctx, 2*time.Second)，不能依赖 client 层设置 - 重试建议指数退避：失败后
time.Sleep(100 * time.Millisecond)→200ms→400ms，最多 3 次，避免雪崩
寄存器值字节序反了？先看设备手册再动 binary
常见现象：ReadHoldingRegisters 返回 []uint16{0x1234, 0x5678}，但设备文档说这是 float32 的 3.14。别急着用 binary.LittleEndian 硬转 —— 很可能设备用的是“寄存器高位在前、字内低位在前”的混合序（如 AB-CD 模式），或浮点数跨两个寄存器且需按 IEEE 754 拆解。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 查设备手册确认字节序约定：是 big-endian uint16 数组，还是 little-endian float32 两寄存器拼接
- 用
binary.Write+bytes.NewReader构造测试 payload，比对原始报文 hex dump - 如果设备只支持 RTU over RS485，
gobit不直接支持帧构造，得配合gorilla/serial手动组包；此时可退用mbgo.RTUClient，但务必加sync.Mutex串行读写串口
自定义二进制协议必须带长度头，否则必粘包
net.Conn 是纯字节流，不解决分包问题。直接 conn.Write(myStruct) 会 panic，因为 struct 不是 []byte；就算序列化了，没长度头，接收方根本不知道该读多少字节。
- 最简方案：4 字节大端长度头 + payload，用
binary.BigEndian.PutUint32(header, uint32(len(data))) - 接收端必须用
io.ReadFull读满长度头，再读满 payload，裸conn.Read可能只读到半包 - 字段含字符串时，别用 Go struct 直接
binary.Read—— 非导出字段被跳过，[]byte和string长度不匹配，建议先读整块再手动bytes.TrimRight(data, "\x00")
设备协议解析真正的难点不在编解码，而在和硬件“对齐”：同一个寄存器地址，不同厂商手册可能定义成 int16 / uint16 / float32 / BCD，甚至字节序拆分方式都不一致。上线前一定拿真实设备跑 hex dump 对照，别只信文档。
