需对比Golang序列化方案因性能直接影响微服务/RPC/缓存的吞吐与延迟；json易用但慢，gob快但不跨语言，protobuf/msgpack/cbor等各有所长，应依数据结构、跨语言需求、内存与体积敏感度选型。
为什么需要对比Golang序列化方案
在微服务、RPC通信或缓存场景中，序列化性能直接影响吞吐量和延迟。Go原生的encoding/json易用但较慢；gob快但不跨语言；而protobuf、msgpack、cbor等第三方方案各有取舍。做基准测试（benchmark）不是比“谁绝对最快”，而是看：数据结构是否复杂、是否需跨语言、内存分配是否可控、编码后体积是否敏感。
统一测试方法才能公平对比
用go test -bench跑压测时，关键要控制变量：
- 被测结构体保持一致（例如含嵌套、指针、slice、time.Time等典型字段）
- 每次Benchmark函数内都新建实例，避免复用导致GC干扰
- 显式调用
runtime.GC()前清空堆（可选，适合对比内存分配） - 用
b.ReportAllocs()开启内存统计，关注allocs/op和B/op - 运行多次（如
-count=5）取中位数，避开瞬时抖动
主流方案实测表现（基于Go 1.22 + 典型结构体）
以一个含5个字段（string、int64、[]byte、map[string]int、time.Time）的结构体为例，千次编解码平均结果大致如下（单位：ns/op）：
- json：~8500 ns/op｜~1200 B/op｜~12 allocs/op｜人类可读，调试友好
- gob：~2100 ns/op｜~750 B/op｜~5 allocs/op｜Go专属，二进制紧凑，但无schema演化支持
- protobuf (proto-go)：~900 ns/op｜~420 B/op｜~2 allocs/op｜需.proto定义，强类型，跨语言首选
- msgpack：~1300 ns/op｜~480 B/op｜~3 allocs/op｜无需IDL，兼容JSON结构，Go/Python/JS生态好
- cbor：~1100 ns/op｜~450 B/op｜~2 allocs/op｜RFC 8949标准，对map/slice编码更紧凑，适合IoT
注意：实际数值受Go版本、CPU缓存、数据内容影响较大，务必在目标环境复测。
立即学习“go语言免费学习笔记（深入）”；
怎么选？看这三点就够了
要跨语言且长期维护 → 选 Protocol Buffers（配合protoc-gen-go生成代码，零拷贝可选gogoproto）
纯Go内部通信、追求简单轻量 → 选 Gob 或 Msgpack（gob省心，msgpack更灵活）
对体积敏感、设备资源受限（如嵌入式）→ 试 CBOR 或 FlatBuffers（后者零拷贝但需预生成schema）
不建议为“理论上快”引入复杂工具链。如果JSON已满足QPS要求，就别换——可维护性常比10%性能提升更重要。
基本上就这些。写bench时多打几行fmt.Printf验证编解码正确性，比单纯追求数字更有意义。
