net/http和ReverseProxy不适用于工业硬件网关，因其缺失TCP底层控制：未禁用Nagle算法、无读写deadline、buffer分配低效、缺乏帧解析与重试逻辑；必须手动管控连接延迟、缓冲、保活及超时。
直接用 net/http 或 httputil.ReverseProxy 做工业硬件网关，90% 会在现场崩溃——不是功能不全，而是 TCP 底层控制完全缺失，丢包、卡死、CPU 满载是必然结果。
为什么 net/http + ReverseProxy 在工业场景下必然失效
Modbus/TCP、IEC 60870-5-104、自定义二进制协议等工业流量，和 HTTP 完全是两类东西：前者无状态、低频、强时序、依赖精确帧边界；后者有完整解析栈、连接复用、语义化 header。一旦套用 HTTP 模型，问题立刻暴露：
-
ReverseProxy不调用SetNoDelay(true)，Nagle 算法把多个小 Modbus 请求攒成一批发，设备端超时断连 - 它对
net.Conn的读写 deadline 完全无感知，一次阻塞Read就让整个 goroutine 卡死几十秒，无法响应其他设备 -
io.Copy默认分配 32KB buffer，高频轮询下 GC 频繁触发，CPU 跑满但实际吞吐不足 30% - 它不处理帧头校验、异常响应码映射（如 Modbus 异常码 0x02 → “非法地址”）、重试退避逻辑，这些都得自己补，但补在 HTTP 层上极其别扭
必须手动接管的四个 TCP 生命周期控制点
工业现场网络抖动是常态，不能靠“重连”兜底，必须在连接建立、传输、空闲三阶段做精细干预：
- Accept 后立即类型断言：
if tcpConn, ok := conn.(*net.TCPConn); ok { tcpConn.SetNoDelay(true) } - 每个连接配独立
bufio.Reader和bufio.Writer，buffer 大小设为32 * 1024，且用sync.Pool复用整个 reader/writer 实例，避免堆分配 - 启用 OS 级 keep-alive：
tcpConn.SetKeepAlive(true)+tcpConn.SetKeepAlivePeriod(45 * time.Second)，比应用层心跳更轻量可靠 - 每次
Read/Write前动态设置 deadline：conn.SetReadDeadline(time.Now().Add(2 * time.Second))，超时值按功能码区分（例如读寄存器设 2s，写单个设 500ms）
如何安全并发读取多个 PLC 设备
一主多从拓扑下，起一堆 goroutine 轮询看似简单，实则极易触发调度器雪崩或全局阻塞：
立即学习“go语言免费学习笔记（深入）”；
- 禁止裸写
go client.ReadHoldingRegisters(...)—— 某台 PLC 离线时，该 goroutine 会永远阻塞在Read，且无法被取消 - 必须用
context.WithTimeout包裹每次调用，并确保底层 transport 支持 context 取消（goburrow/modbus支持，但需显式传入） - 连接池要带健康检查：每次使用前发一个极简探测帧（如 Modbus 0x03 读 0 寄存器），失败则标记为不可用并触发后台重连，而非等待超时
- goroutine 数量必须硬限流，建议用带容量的 channel 当信号量：
sem := make(chan struct{}, 100)，acquire 时sem ，done 时 <code><-sem
ALPN 共端口陷阱：MQTT over TLS、HTTPS、私有协议混用 443 端口时必踩
想让 MQTT、HTTPS、自定义 TLS 协议共用一个 443 端口？光靠 tls.Listen 不够，ALPN 协商失败会导致设备反复重连但网关无日志：
- 必须显式配置
tls.Config.NextProtos，例如：[]string{"h2", "http/1.1", "mqtt"} - MQTT 客户端必须支持 ALPN 并声明
"mqtt"，否则握手卡在ChangeCipherSpec阶段 - 网关 Accept 后，需立即调用
conn.ConnectionState().NegotiatedProtocol分流，而不是统一走 HTTP 解析流程 - 未协商出协议时，应主动关闭连接并记录
"ALPN negotiation failed"，避免堆积无效连接
真正难的不是写转发逻辑，而是把每个 net.Conn 当成需要呼吸、心跳、喂食、清理的生命体来对待——工业环境里，连接不是资源，是现场设备的延伸神经，断一根，产线就停。
