gnet不是初学者该优先碰的网络库，它适合已有net/http或raw net.conn实战经验、明确遇到10k+并发或内存gc压力的人；它是传输层框架，不处理http协议解析、路由、中间件等应用层逻辑，需手动拼http报文，代码量远超net/http且易违反rfc。
直接上结论：gnet 不是初学者该优先碰的网络库，它适合已有 net/http 或 raw net.Conn 实战经验、明确遇到 10k+ 并发或内存 GC 压力的人。用错场景反而增加理解负担。
为什么不能把 gnet 当成 net/http 的替代品来学？
gnet 是传输层框架，不处理 HTTP 协议解析、路由、中间件、JSON 编解码这些应用层逻辑。你写一个 gnet.Serve 启动服务后，收到的是原始字节流，不是 *http.Request；你要自己实现 GET /health 解析、状态码返回、header 写入——这些在 net/http 里一行 w.WriteHeader(200) 就搞定的事，在 gnet 里得手动拼 HTTP 报文。
- 新手拿 gnet 写“Hello World”服务器，代码量是 net/http 的 5 倍以上，且极易写出不符合 RFC 的响应
- gnet 的
React方法每毫秒可能被调用数千次，调试时打log.Println会直接拖垮吞吐量 - 它默认关闭 goroutine-per-connection，但如果你在
React里启动 goroutine 处理业务，又没配ants池，很容易触发调度风暴
什么情况下该切到 gnet？看这三个信号
当你发现以下任一现象持续存在，且已确认瓶颈不在业务逻辑本身时，gnet 才是合理选择：
-
pprof显示runtime.mcall或runtime.gopark占 CPU 超过 30%，说明 goroutine 切换开销过大 - 压测中连接数升到 2w 后，
go tool pprof --alloc_space报告net.Conn.Read和bytes.Buffer.Write是 top2 分配源 - 用
net/http实现的长连接服务（如 MQTT broker、自定义协议网关），单机稳定承载低于 5k 连接，且top中 RES 内存持续增长不回收
这时迁移到 gnet 才有实感收益——实测中，同硬件下从 net/http 切到 gnet，10w 连接时 GC pause 从 8ms 降到 0.3ms，CPU 占用下降 42%。
第一次用 gnet 写 TCP 回显服务，必须绕开的三个坑
别照抄文档里的 echo 示例直接上线。真实环境里这几个点不处理，服务跑半天就卡死：
-
React返回的out []byte如果超过缓冲区容量（默认 64KB），gnet 会阻塞写入直到对端读走数据——你得在OnTraffic里加c.AsyncWrite避免同步阻塞 - 没设
gnet.WithTicker(true)时，OnTick不触发，导致连接空闲超时、心跳检测、内存池回收全部失效 - 用
gnet.WithMulticore(true)但没配gnet.WithLoadBalancing(gnet.LeastConnections)，Linux 下多核 CPU 可能出现某 core 100% 而其他 core 空转
最小可用 TCP 服务模板里，至少要包含 OnOpen 记录连接 ID、OnClose 清理资源、OnTraffic 控制读写节奏——这三处漏掉任意一个，百万连接下都会出隐蔽泄漏。
gnet 的价值不在“快”，而在“可控”。它把 epoll/kqueue、ring buffer、goroutine pool 这些黑盒全摊开给你调，但代价是你得懂每个开关拧多了会崩哪根线。真要用，先拿 gnet/v2 跑通一个带连接计数和内存池监控的 TCP 服务，再考虑协议层封装。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
