encoding/gob 是 Go 中唯一天然适配 TCP 高频小包的序列化方案，因其编译期生成 codec、直写内存布局、无文本解析和字段名打包，性能远超 JSON；需同版本同结构体定义、导出字段、禁用 Nagle 算法，并正确复用 Encoder/Decoder 实例。
encoding/gob 是 Go 语言中唯一能天然适配 TCP 高频小包场景的序列化方案，它不是“学习优化”，而是直接利用 Go 类型系统与标准库的深度协同。其他语言的序列化（如 JSON、Protobuf）在 Go 中引入额外解析开销，反而拉低效率。
为什么 gob 比 json.Marshal 快得多
Go 的 encoding/gob 不做文本解析、不依赖反射运行时遍历字段（编译期生成 codec）、不打包字段名，只按内存布局直写二进制流。实测同结构体：gob 序列化耗时约为 json 的 1/5，体积减少约 40%。
-
gob要求 client/server 使用相同 Go 版本和 struct 定义（包括导出字段顺序），否则解码失败 —— 这不是 bug，是设计约束 - 不能跨语言通信；若需兼容 Java/Python，必须换用
protobuf或msgpack，但性能必然下降 - struct 字段必须以大写字母开头（导出），否则
gob忽略该字段
net.Conn 直接对接 gob.Encoder 的正确姿势
别手动 conn.Write(gobBytes)，那会丢掉类型信息且无法流式编码。必须用 gob.NewEncoder(conn) 和 gob.NewDecoder(conn) 绑定连接生命周期：
// 正确：复用 encoder/decoder 实例，避免重复分配
enc := gob.NewEncoder(conn)
dec := gob.NewDecoder(conn)
// 发送
err := enc.Encode(&MyStruct{X: 1, Y: "hello"})
// 接收
var s MyStruct
err := dec.Decode(&s)
- 每个
conn对应独立的Encoder/Decoder，不可跨连接复用 - 它们内部已自带缓冲（底层调用
bufio.Writer），无需再套一层bufio—— 多套反而增加拷贝 - 若需控制缓冲大小（如 64KB），可先用
bufio.NewWriterSize(conn, 65536)构造 writer 再传给gob.NewEncoder
高频小包下必须禁用 Nagle 算法
默认开启的 Nagle 算法会合并多个小 Write 调用，导致几十毫秒延迟。对每秒一次以上的指标上报类场景，这是致命问题：
- 必须在
net.Dial返回的conn上立即调用conn.SetNoDelay(true) - 这个调用要在任何
Write或gob.Encoder操作之前执行，否则可能被忽略 - 服务端
accept后的conn同样要设 —— 单边设置无效
连接池 + gob 的组合陷阱
用 sync.Pool 缓存 *gob.Encoder/*gob.Decoder 是常见误区：
立即学习“go语言免费学习笔记（深入）”；
-
gob.Encoder持有io.Writer引用，而net.Conn是有状态的，不能复用到不同连接 - 真正该池化的，是预分配的
struct实例或临时bytes.Buffer（如果不用net.Conn直连） - 长连接场景下，连接池管理的是
net.Conn本身；gob编解码器应随连接创建/销毁，而非池化
最易被忽略的一点：gob 编码器内部维护类型缓存（gob.typeCache），首次 Encode 同一类型较慢，但后续极快 —— 所以冷启动连接的首条消息延迟偏高，需在连接建立后主动 Encode 一个 dummy struct 预热。
