gnet是目前Go生态中唯一能支撑千万级MQTT/GB/T 32960网关的异步网络库，因其绕过paho.mqtt.golang等客户端SDK，从TCP层重写协议解析与连接生命周期管理，支持百万级并发连接、统一QoS状态管理及底层可控的鉴权与限流。
直接上结论：gnet 是目前 go 生态中唯一能支撑千万级 mqtt/gb/t 32960 网关的异步网络库，前提是绕过 paho.mqtt.golang 这类客户端 sdk，从 tcp 层重写协议解析与连接生命周期管理。
为什么不能用 paho.mqtt.golang 做网关入口
它根本不是服务端框架——Connect() 是阻塞握手、不暴露 net.Conn、每个设备连接都起一个独立 client 实例。结果就是：
- 10 万连接 ≈ 10 万个 goroutine + 10 万份 session 状态，内存暴涨、调度失衡
- QoS 2 的 PUBREC/PUBREL 流程无法跨连接统一管理，状态散落在各 client 实例里
- ACL、retain 消息投递、路由分发这些网关核心逻辑全得自己重写，等于在客户端 SDK 上盖楼
- TLS 分流、报文预检、连接限速等底层控制完全不可介入
gnet.React 中安全解析 MQTT CONNECT 报文
MQTT 固定头只有 2 字节，但剩余长度字段是变长编码（1–4 字节），直接 conn.Read(buf[:2]) 后就 decode 会越界或截断。必须手动做缓冲提取：
- 在
OnOpened回调里为每个连接分配固定 buffer（如 1024 字节），绑定到c.Context()，避免每次 React 都make([]byte) -
React入口先检查ctx.offset < 2：不够就return nil, gnet.None，等下次事件触发 - 解析前 2 字节后，按 MQTT 规范循环计算剩余长度字节数：
(b & 0x7F) << shift，再判断当前ctx.offset是否 ≥ 总长度 - buffer 不足时暂存已读数据，严禁 在
React里调用fmt.Println、DB 查询或任何阻塞操作，否则整个 event-loop 卡死
设备 ID 提取与边收边验的鉴权时机
CONNECT 报文的 clientID、username、password 都在 payload 区，未加密且位置可算。不能等整包收完再鉴权——恶意连接可能只发半个包耗尽你的 buffer：
- 在解析出固定头、确认是 CONNECT 类型后，立即根据 payload offset 和 length 计算出 clientID 起始位置
- 只要 buffer 已覆盖 clientID 区域（哪怕 password 还没到），就调用 ACL 模块做白名单校验
- 校验失败立刻
c.Close()，并清空ctx.buf和ctx.offset，防止残留数据干扰下一次连接 - 鉴权逻辑必须是纯内存操作（查 map / bloom filter），禁止 IO 或锁竞争，否则拖慢整个 event-loop
eventloop.cache 内存泄漏的真实风险点
gnet 的 eventloop.cache 是个裸 map[int]*conn，没有过期机制。连接异常中断（如 RST、超时）时，delConn 可能没执行完就被 GC 中断，导致 conn 对象长期驻留内存：
- 检查
eventloop_unix.go和eventloop_windows.go中closeConn的清理路径是否全覆盖所有关闭场景 - 在
OnClosed回调里显式从el.cache中delete对应 fd，并设c = nil防止悬挂引用 - 用
pprof定期抓取 heap profile，过滤*gnet.conn类型，确认其数量是否随连接数线性增长 - 不要依赖 “连接数下降后内存自动释放” —— gnet 的 conn 对象若被闭包或日志句柄意外持有，GC 就不会回收
