必须显式设置动态超时、注册ponghandler、预序列化发送、单goroutine轮询、规则预编译缓存及编译优化；否则弱网、高并发、长期运行下易崩溃。
Go 适合做边缘网关，但默认写法在真实工业现场大概率会崩——不是性能不够，而是资源调度、协议容错、内存生命周期没对齐边缘场景的真实约束。
gorilla/websocket 在弱网下频繁断开怎么 fix
直接用 gorilla/websocket 默认配置跑 MQTT over WebSocket，设备端一抖动就报 websocket: close sent 或 i/o timeout，本质是连接保活机制和业务节奏脱节。
- 必须显式设置
WriteDeadline和ReadDeadline，且不能硬写time.Second * 30；建议按设备心跳周期动态设，例如设备每 5 秒发一次心跳，deadline 就设为time.Second * 15 - 务必注册
SetPongHandler，否则远端发 PONG 时 Go 会静默关闭连接；handler 至少打一行日志，别留空函数 -
WriteMessage前避免 JSON 序列化 + 加密等耗时操作；应提前序列化成[]byte，塞进带缓冲的chan []byte，由独立 goroutine 拉取发送
modbus 轮询导致 CPU 爆满的典型误用
起一个 goroutine 对每个设备做 for { read(); time.Sleep(1 * time.Second) }，20+ 设备时 goroutine 数量轻松破千，ARM Cortex-A7 核心直接被调度开销拖垮。
- 改用单 goroutine + 多设备时间片轮询：维护一个设备队列，每次读完一个设备后计算下次读取时间戳，用
heap或timer触发下一轮，总 goroutine 数控制在个位数 - 读取超时必须设（如
client.Timeout = 300 * time.Millisecond），否则某个设备掉线会阻塞整个轮询链 - 复用
modbus.Client实例，不要每个请求都 new 一个；连接池靠net.Dialer.KeepAlive+http.Transport类似思路管理
expr.Eval 规则引擎长期运行后 RSS 持续上涨
每次收到规则字符串都调 expr.Compile(ruleStr)，AST 对象不会被 GC 回收，几周后内存占用翻倍是常态。
- 所有规则必须预编译并缓存，key 用
sha256.Sum256([]byte(ruleStr)).String()，value 是*expr.Program -
expr.Program是线程安全的，可全局复用，别在 handler 里反复 compile - 规则体必须是纯函数；真要调外部 API，走独立的 action dispatcher 异步触发，绝不塞进
expr.Eval执行流
编译参数不调，二进制体积和内存占用白丢 40%
直接 go build 出来的网关二进制，在树莓派上跑几天 RSS 就涨到 300MB+，其实一半是调试符号和反射元数据撑的。
- 加
-ldflags="-s -w"去符号表，体积减少 30%，启动内存下降明显 - 交叉编译时禁用 cgo：
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -a -installsuffix cgo - 规则引擎若含大量嵌套
and/or，预编译缓存后配合-gcflags="-l"关闭内联，反而更省内存
边缘网关最难的从来不是“连得上”，而是“连得久”——所有超时、重试、缓存、编译时机，都得按设备心跳、网络抖动、CPU 负载这些物理指标来校准，而不是按开发机上的理想值硬编码。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
