不能直接用net/http+reverseproxy做modbus/tcp网关，因其将二进制协议误作http处理：不调用setnodelay导致nagle算法攒包、无读写deadline致goroutine卡死、io.copy高频分配32kb切片引发gc压力大，且完全缺失modbus帧头校验、异常码映射、重试退避等协议层逻辑。
为什么不能直接用 net/http + ReverseProxy 转发 Modbus/TCP
Modbus/TCP 不是 HTTP，httputil.ReverseProxy 会把它当 malformed HTTP 流处理——连接建立后，http.Transport 完全不感知 raw TCP 的读写状态，导致三类硬伤：
• SetNoDelay(true) 不被调用，Nagle 算法攒包，设备端收不到及时响应，超时断连
• 没有 SetReadDeadline，一次阻塞读会让 goroutine 卡死几十秒，轮询链全堵死
• io.Copy 默认分配 32KB slice，高频轮询下 GC 频繁，CPU 跑满但带宽利用率不足 30%
更关键的是，它压根不处理 Modbus 帧头校验、异常响应码（如 0x84）、重试退避等协议层逻辑，这些必须手写。
如何正确初始化和管理 *net.TCPConn
Accept 到连接后，必须立刻做类型断言并设置底层参数，不能依赖任何 HTTP 中间件封装：
- 强制断言：
if tcpConn, ok := conn.(*net.TCPConn); ok { tcpConn.SetNoDelay(true) } - 启用保活：
tcpConn.SetKeepAlive(true)+tcpConn.SetKeepAlivePeriod(45 * time.Second)，比应用层心跳更轻量可靠 - 每个连接独占
bufio.Reader和bufio.Writer，buffer 大小设为32 * 1024，且整个reader/writer实例用sync.Pool复用，避免每次分配对象 - 每次
Read或Write前，动态调用SetReadDeadline/SetWriteDeadline，超时值按功能码区分：读寄存器设2 * time.Second，写单个线圈设500 * time.Millisecond
怎么安全轮询多个 PLC 设备而不崩调度器
起一个 goroutine 对每个设备 for { read(); time.Sleep(1 * time.Second) } 是典型反模式——20 台设备就上千 goroutine，ARM Cortex-A7 核心光调度开销就能拖垮。真实可行的方案是单 goroutine 时间片轮询：
- 维护一个设备队列，每个设备记录下次轮询时间戳（
nextPollAt） - 用最小堆或
time.Timer触发下一轮，总 goroutine 数控制在个位数 - 每个设备使用复用的
modbus.Client实例，不要每次 new；连接池靠net.Dialer.KeepAlive管理 - 读取前必须设
client.Timeout = 300 * time.Millisecond，否则一台掉线设备会阻塞整个轮询链
哪些地方最容易内存泄漏或 CPU 暴涨
工业网关长期运行最常踩的坑不在业务逻辑，而在资源生命周期管理：
- MQTT/Modbus 握手失败分支里忘了
conn.Close()，goroutine 卡在conn.Read()上，几分钟内协程数破 5 万 - 规则引擎每次收到字符串都
expr.Compile(ruleStr)，AST 对象不被 GC 回收，几周后 RSS 翻倍；必须预编译缓存，key 用sha256.Sum256([]byte(ruleStr)).String() - 没加
-ldflags="-s -w"编译，调试符号和反射元数据撑大二进制，树莓派上几天 RSS 就涨到 300MB+ - 日志里直接
fmt.Printf("%x", rawBytes)打印原始帧——Modbus/TCP 密码字段明文泄露，安全红线
真正难的不是写通功能，而是让连接不死、内存不涨、CPU 不飘、密钥不泄——这些点藏在协议握手、超时设置、对象复用和编译参数里，漏掉任一个，现场就出问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
