在分布式系统和微服务架构中，序列化是数据传输的咽喉。Go 语言生态提供了从标准库到高性能第三方库的多种方案，选择不当可能导致数十倍的性能差距和显著的内存分配开销。本文对比主流序列化技术，帮助你在不同场景下做出最优决策。
一、Go 原生序列化：gob
Go 标准库自带的 encoding/gob 专为 Go 运行时设计。它能自动处理复杂类型（如 map、slice、接口类型），并支持递归数据结构。优势在于与 Go 语言的无缝集成：编码器可直接读写 io.Writer/io.Reader，且对未导出字段有特殊处理能力。
但 gob 的代价同样明显：性能较差。其基于反射的类型描述机制在每次编码时都会重新解析结构，且生成的二进制体积较大（包含完整的类型元数据）。更关键的是跨语言支持几乎为零——其他语言没有现成的 gob 解析器。因此 gob 仅适合纯 Go 环境的进程间通信或持久化存储，且对性能要求不高的场景。
二、JSON：通用但低效
encoding/json 是 Go 中使用最广泛的序列化格式。它的最大优势是跨语言通用性和人类可读性。然而性能方面，标准库 JSON 表现平庸：大量使用反射，每个字段名都要写入字符串，数字默认解析为 float64 导致精度转换开销。对于高频服务，JSON 序列化可能占据 CPU 时间的 10%-30%。
社区改进方案如 json-iterator/go 通过替代反射实现和缓存优化，可提升 2-3 倍性能，同时保持 API 兼容。更极端的 sonic 利用 JIT 和 SIMD 指令，在 Intel 架构上能达到标准库 5-10 倍的吞吐量，但增加了编译依赖和平台限制。
三、Protocol Buffers：标准之选
Google 的 protobuf 是性能与兼容性的平衡点。它通过 .proto 文件定义 schema，再生成代码，完全规避了运行时反射。编码采用 Varint 和固定长度等紧凑方式，无需写入字段名（只写入数字 tag），体积通常比 JSON 小 30%-50%。
Go 生态中有两个主流实现：官方 google.golang.org/protobuf 已经完全成熟，新版采用确定性 API 和更好的内存管理。而 gogo/protobuf 通过代码生成时的深度优化（如自定义字段选项、更激进的指针消除）可再提升 20%-30% 性能，但已逐渐不再维护。
protobuf 的代价是需要维护 .proto 文件和代码生成步骤，且二进制不可读，调试困难。适合跨语言 RPC 系统（如 gRPC）、长期存储的日志或事件数据。
四、MessagePack：JSON 的二进制变体
MessagePack 的核心思想是“JSON 的二进制版”——保留 JSON 的动态类型结构，但用更紧凑的字节码表示。例如 {"name":"Tom"} 在 JSON 中是 15 字节，在 MsgPack 中约 10 字节。Go 的 vmihailenco/msgpack 支持 struct tag 注解，兼容性良好。
相比 protobuf，MsgPack 不需要预先定义 schema，灵活性更高，适合数据结构频繁变动的场景。但代价是解析时仍需处理类型信息，速度介于 JSON 和 protobuf 之间，且跨语言生态不如 protobuf 成熟。
五、高性能竞品：FlatBuffers 与 Cap'n Proto
当性能要求达到极致（如游戏状态同步、高频交易），应直接考虑零拷贝序列化方案。
FlatBuffers 由 Google 为游戏开发而生。它允许访问序列化数据而无需先解压拷贝：数据本身就是内存友好的布局，通过偏移量直接索引字段。Go 的 flatbuffers 支持需要手动编写 schema 并生成访问器代码。读取任意字段的时间复杂度为 O(1)，且不产生任何垃圾回收压力。代价是编码过程较复杂，schema 变更需要额外处理兼容性。
Cap'n Proto 更进一步，连编码步骤都省了——序列化的内存结构本身就是数据传输格式，直接通过共享内存或 RDMA 发送。Go 实现较为成熟，但指针模型与 Go 的 GC 有些摩擦，需要谨慎管理生命周期。
六、选择决策框架
根据场景确定方案：
- 跨语言 RPC + 性能敏感：protobuf（官方版本）。生态完善，性能足够，工具链成熟。
- 纯 Go 内部通信，极致简化：gob 或直接使用 struct 二进制布局（
encoding/binary）。后者需要手动处理大小端，但零依赖且极快。 - 与前端或外部 API 交互：JSON 不可避免。此时优先尝试
sonic（如果部署在 Intel CPU），否则用json-iterator。 - 延迟毫秒级以下，数据量巨大：FlatBuffers。避免反序列化开销的同时控制内存分配。
- 临时数据存储，schema 会变：MessagePack。比 JSON 快且省空间，改结构无需重新生成代码。
七、性能验证不可省略
不同库在结构体大小、字段类型、数据重复率上的表现可能截然相反。例如嵌套结构下 protobuf 的优势放大，而大量布尔值用 msgpack 的变长编码反而低效。务必用 go test -bench 配合真实负载规模和字段组合进行实测，同时关注内存分配次数（allocs/op）——在 Go 中，减少分配往往比减少 CPU 指令更重要。
最终，最佳序列化方案不是“最快的那一个”，而是在速度、空间、易用性、兼容性之间取得平衡，且符合你系统约束的那一个。