真正支撑百万级MQTT并发需重写TCP连接模型，绕过net.Conn抽象，用gnet event-loop直管字节流；paho.mqtt.golang仅适合作为客户端SDK，其阻塞Connect、goroutine膨胀、无法底层控制等缺陷使其完全不适用于网关入口。
不能直接把 paho.mqtt.golang 换成 gnet 就算“重构完成”——那只是替换了客户端 SDK，没碰到底层连接模型。真正要支撑百万级并发，必须从 TCP 连接收口重写，绕过标准 net.Conn 抽象，用 gnet 的 event-loop 直接管住每一个字节流。
为什么 paho.mqtt.golang 不能当网关入口
paho.mqtt.golang 的 Connect() 是阻塞调用，内部封装了完整 session 生命周期管理，还自带 goroutine 调度和重连逻辑。你每 accept 一个设备连接就 new 一个 Client，等于在服务端硬模拟十万台客户端：
- 每个
Client占用独立 goroutine，runtime.NumGoroutine()在 5 万连接时就破 12 万 - 不暴露底层
net.Conn，无法做 TLS 分流、报文预检、连接限速等网关级控制 - ACL、路由、retain 消息投递全得自己重写，QoS 2 状态分散在每个实例中，超时/重传极易错乱
- GC 频率飙升到每秒 3–5 次，延迟毛刺明显——这不是业务瓶颈，是架构误用
gnet.React 中必须手动缓冲 + 定长提取 MQTT 报文
MQTT CONNECT 报文头固定 2 字节，但剩余长度字段是可变字节数（最多 4 字节），直接 conn.Read(buf[:2]) 后 decode 会越界或截断。gnet 不自动分包，必须自己实现缓冲与长度解析：
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 在
gnet.OnOpened里为每个连接分配固定 buffer（如 1024 字节），绑定到c.Context()，避免每次React都 malloc -
React开头先检查已读字节数是否 ≥ 2；不够就return nil, gnet.None，等下次事件触发 - 解析前 2 字节后，按 MQTT 规范循环计算剩余长度字段实际字节数：
(b & 0x7F) ，再判断当前 buffer 是否足够 - 不足就暂存已读数据，不 panic、不丢包、不阻塞 event-loop
鉴权不能等完整 CONNECT 报文收齐
CONNECT 报文的 clientID、username、password 都在 payload 区，未加密。恶意连接可能只发半个报文耗尽 buffer，所以得边收边验：
立即学习“go语言免费学习笔记（深入）”；
- 收到前 2 字节后，立即解析出 type 和剩余长度字段，预估总长度
- 若总长度 > buffer 容量，直接拒绝并 close 连接，防内存耗尽
- 若长度合理，在后续
React中逐段提取 payload，并在第一个完整 packet 到达时立刻查 ACL 表 - 严禁在
React中调fmt.Println、time.Sleep或 DB 查询——整个 event-loop 会卡死
连接复用和协议解析才是真实瓶颈
换 CBOR、调高 QoS、加 Redis 缓存都解决不了根本问题。压测显示：单机维持 100 万并发连接时，90% 的 CPU 时间花在 net.Conn.Read 和 bytes.Buffer.Write 上。gnet 绕过标准 net 包，直接操作 epoll/kqueue，配合 Ring-Buffer 内存池，把单连接内存开销压到 2KB 以内。但这也意味着你不能再依赖 bufio.Reader 或 http.Request 那套惯性思维——所有协议解析必须手写状态机，且不能有阻塞 IO。
