游戏服务器核心通信层必须用 net 包直连 TCPConn，因 net/http 带 HTTP 头、状态码等冗余开销，无法满足实时对战帧同步需求，且不支持心跳、断线检测、粘包处理。
用 net/http 还是 net 写 TCP 服务？
游戏服务器核心通信层不能靠 net/http——它带 HTTP 头、状态码、连接复用逻辑，纯增开销。实时对战、帧同步场景下，net 包直连 TCPConn 才可控。
常见错误：用 http.Serve 接客户端二进制协议包，结果读到一半卡在等待换行或 header 解析，连接直接超时断开。
- 心跳、断线检测、粘包处理都得自己写，
http.Server不提供这些能力 -
net.Listen("tcp", ":3000")后用conn.Read()拿原始字节，别碰bufio.Reader除非你明确控制分包边界 - 如果真要用 HTTP（比如登录/配置接口），单独起一个
http.Server绑不同端口，和主游戏逻辑隔离
怎么安全地并发处理玩家连接？
每个 net.Conn 单独起 goroutine 是最直接做法，但必须配资源回收和上下文控制，否则 goroutine 泄漏比内存泄漏更快见底。
典型现象：压测时 CPU 稳定 100%，runtime.NumGoroutine() 持续上涨，pprof 显示大量阻塞在 conn.Read() 或 select 上。
- 给每个连接 goroutine 加
context.WithTimeout，超时后主动conn.Close() - 用
sync.Pool复用[]byte缓冲区，避免高频分配触发 GC - 禁止在连接 goroutine 里直接调用数据库或 RPC——改用消息队列或 worker pool 异步处理
encoding/binary 解包为什么总出错？
游戏协议基本是二进制小端序（如 Unity 客户端默认），但 Go 的 binary.Read 默认不校验字节序，传错 binary.LittleEndian 或 binary.BigEndian 就会读出完全错误的 ID、坐标、时间戳。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
错误示例：binary.Read(r, binary.BigEndian, &header.Len) 配合 Unity 发来的小端包，Len 变成 65536 倍大值，后续直接越界 panic。
- 协议文档没写字节序？抓包看前 4 字节，用
hexdump -C对比已知数值反推 - 结构体字段必须用
struct{}+binary.Read，别用unsafe.Pointer强转——跨平台或 GC 移动后地址失效 - 长度字段之后的数据，一定要用
io.LimitReader(conn, int64(expectedLen))包一层，防恶意客户端发超长包
热更新代码时怎么不踢玩家？
Go 本身不支持热加载，所谓“热更新”实际是进程平滑重启：新进程启动监听同一端口，旧进程等所有连接自然断开或超时退出。关键在 net.Listener 的文件描述符传递。
踩坑最多的是用 syscall.Dup() 自己传 fd，结果新进程绑定失败，或旧进程关 listener 时连带关闭了新进程的连接。
- 用
github.com/freddierice/go-restart或github.com/fsnotify/fsnotify+os/exec.Command("kill", "-USR2", pid)更稳妥 - 监听
SIGUSR2信号，在 handler 里用l, err := net.FileListener(f)从父进程继承 listener - 旧进程不能立刻
os.Exit()，要等activeConnCount == 0或time.AfterFunc(30*time.Second, os.Exit)
真正难的不是换进程，是状态迁移——玩家背包、位置、技能 CD 这些内存数据，得提前存到 Redis 或本地 mmap 文件，新进程起来再捞。这块没现成方案，得自己权衡一致性与延迟。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
