不能直接用 net.conn 做连接池管理，因 goroutine 无法自动回收、超时缺失会导致泄漏，千级连接即可拖垮调度器；须用状态机控制生命周期，sync.pool 复用包装对象而非 fd，配读写超时、主动心跳、长度前缀解包、accept 层限流、so_reuseport 负载均衡、异步鉴权、环形缓冲区暂存消息，并分三步优雅关闭。
为什么不能直接用 net.Conn 做连接池管理
直接对每个 net.Conn 启一个 goroutine 处理读写，看似简单，但会在连接数上升后迅速失控。goroutine 不会自动回收，conn.Read() 阻塞时它就一直挂着；若客户端异常断开而服务端没做超时或心跳检测，这个 goroutine 就永久泄漏。千级连接可能拖垮调度器，万级连接大概率触发 GC 频繁、内存暴涨甚至 OOM。
真正可行的方案是：把连接生命周期交给显式状态机控制，配合 sync.Pool 复用连接上下文对象，而不是复用 net.Conn 本身——因为 net.Conn 是操作系统 fd，不可复用，只能复用其包装结构体和缓冲区。
- 每个连接必须绑定独立的读/写超时（用
conn.SetReadDeadline()/conn.SetWriteDeadline()），不能依赖全局 context 超时 - 心跳包必须由服务端主动发（
PING），并要求客户端回PONG；只靠 TCP keepalive 不够，它默认 2 小时才探测一次 -
sync.Pool应复用struct{ conn net.Conn; buf []byte; decoder *proto.Decoder }这类组合对象，而非裸[]byte
如何正确处理 TCP 粘包与自定义协议解析
游戏协议几乎全是二进制私有协议，没有 HTTP 那种天然分界符。如果直接 conn.Read(buf) 并假设每次读到完整包，必然出错——TCP 不保证“一次 Write 对应一次 Read”。常见错误是收到半包或粘连多包，导致解码失败或 panic。
标准解法是：在协议头固定位置放长度字段（如前 4 字节 uint32 表示 body 长度），然后用循环读取拼装完整包。不要用 bufio.Reader 的 ReadString 或 ReadBytes，它们基于字节匹配，不适用于二进制协议。
- 读取时先读固定头长（如 4 字节），解析出 payload 长度
n - 再循环调用
io.ReadFull(conn, buf[:n])直到填满，期间检查io.EOF和net.ErrClosed - 避免在单次读操作中分配大 buffer；建议用
sync.Pool提供的预分配 slice，长度上限按协议最大包限制（如 64KB） - 解包失败（如长度超限、magic number 错误）必须立即关闭连接，防止恶意构造包耗尽资源
重连风暴下如何避免网关被瞬时流量打穿
玩家地铁切换基站、WiFi 断连重试、服务器滚动更新时，大量客户端在 1–3 秒内密集重连，网关的 accept() 队列和握手逻辑（如 TLS 握手、token 验证）会成为瓶颈。此时 CPU 占用飙升，新连接排队，合法用户也被拒。
关键不是“拒绝连接”，而是“平滑吸收”。必须在 accept 层就做限流，且限流粒度要细——不能只限 IP，得按设备 ID 或 session token 做分布式令牌桶，否则同一玩家多端登录会被误杀。
- 使用
golang.org/x/time/rate.Limiter做每连接限速，但注意它不是并发安全的，需为每个连接实例化一个 - 接入层用 SO_REUSEPORT 绑定多个 listener，让内核均衡分发新连接到不同 goroutine，避免单点锁竞争
- 鉴权逻辑必须异步化：先快速分配 session ID，把 token 校验扔进 worker pool 异步处理，失败再发 disconnect 包
- 对已断线但尚未重连成功的玩家，启用环形缓冲区（ring buffer）暂存下行消息，容量硬限制（如 20 条），超限则丢弃旧消息，防止内存无限增长
优雅关闭时为什么 conn.Close() 不够
调用 conn.Close() 只是关闭 fd，但正在运行的读写 goroutine 可能还在往已关闭的连接写数据，触发 write: broken pipe panic；或者刚读到一半的包被中断，导致客户端收不到完整响应。
真正的优雅关闭必须分三步：通知客户端即将断开 → 等待当前业务逻辑完成 → 回收资源。Go 没有内置机制支持这点，得自己维护连接状态机。
- 给每个连接加一个
ctx, cancel := context.WithCancel(context.Background())，所有读写操作都基于此 ctx - 关闭前调用
cancel()，并在读循环里检查ctx.Err() == context.Canceled，停止读取但不立即 close - 用
sync.WaitGroup记录当前活跃的业务 handler 数量，等为 0 后再调用conn.Close() - 务必设置
conn.SetWriteDeadline(time.Now().Add(5 * time.Second))，防止 write 阻塞太久卡住 shutdown 流程
最易被忽略的是：连接池中的空闲连接，在 shutdown 期间必须被标记为 “不可再分配”，否则新请求可能拿到一个正处在关闭流程中的连接，导致不可预测行为。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
