Go序列化性能测试须用testing.Benchmark并多次运行取统计量，避免GC和调度干扰；需重置数据、报告内存分配、预热；JSON注意omitempty限制及优化选项；Protobuf推荐gogoproto扩展；MsgPack选型需关注nil处理差异。
Go 里测序列化性能，别直接跑 time.Now() 做差值
手动用 time.Now() 和 time.Since() 测单次编码/解码耗时，结果基本没参考价值——GC、调度抖动、CPU 频率波动都会让数字飘得离谱。真实对比必须跑足够多次并取统计量。
- 用
testing.Benchmark，不是main()里随便 call 几次 - 每次
b.Run()内要重置数据，避免复用指针或缓存干扰（比如proto.Marshal后不清空缓冲区，下次可能走短路） - 加
b.ReportAllocs()，内存分配次数比“快多少纳秒”更能暴露库的底层开销差异 - 别忘预热：第一次
json.Marshal比第十次慢 3–5 倍，benchmark 默认会自动 warmup，但自定义循环里不会
json.Marshal 默认不支持 struct 字段零值跳过，但 encoding/json 有坑
很多人以为加 omitempty 就万事大吉，其实它只对零值字段生效，而 Go 的零值判断是静态的：空字符串、0、nil 切片都算零值；但 time.Time{} 不是零值（它有内部字段），sql.NullString{Valid: false} 也不是——这些都会被序列化出来，拖慢速度、增大体积。
- JSON 库里
easyjson或ffjson可生成无反射的 marshaler，比标准库快 2–4 倍，但需额外代码生成步骤 - 如果字段大量为空，优先考虑在 struct 定义时用指针类型（如
*string），再配omitempty，这样 nil 指针会被跳过 - 标准
json包默认禁用SetEscapeHTML(false)，若数据不含 HTML 特殊字符，关掉能省 10%+ 时间
Protobuf 要快，必须用 gogoproto 扩展或 protoc-gen-go v2
原生 google.golang.org/protobuf（v2）已比老版 github.com/golang/protobuf 快不少，但默认生成的代码仍带反射 fallback。真正压榨性能得靠扩展。
- 用
gogoproto的casttype、compare、sizecache注释，能减少 30%+ 解析耗时，尤其对嵌套深、字段多的 message - 务必启用
Size()缓存：加option (gogoproto.sizer) = true;，否则每次Marshal前都要遍历计算长度 - 别忽略
Unmarshal的输入校验开销：Protobuf 默认做完整合法性检查（如负数 enum、重复字段），生产环境可关掉（DiscardUnknown+ 自定义 Unmarshaler）
MsgPack 在 Go 里选 go-codec 还是 msgpack？看是否需要 nil 安全
ugorji/go/codec（现名 go-codec）和 tinylib/msgpack 是主流两个实现，但行为差异明显：前者默认把 nil slice/map 当空值处理，后者直接 panic。
立即学习“go语言免费学习笔记（深入）”；
- 如果结构体字段常为
nil（比如可选配置），用go-codec更省心，且它支持struct`codec:",omitempty"`类似 JSON 的跳过逻辑 -
tinylib/msgpack更轻量、无依赖，但要求所有字段非 nil，否则 benchmark 会崩——调试时看到panic: interface conversion: interface {} is nil就该想到这点 - 两者都不支持浮点数 NaN/Inf 的跨语言兼容序列化，如果数据含这些值，Protobuf 是更稳的选择
真正麻烦的从来不是“哪个库最快”，而是你测的时候用的数据结构是否贴近线上真实负载。字段少、嵌套浅、字符串多？JSON 可能不输。字段密、数值多、传输频？Protobuf 的 size 和 decode 稳定性优势立刻显现。MsgPack 适合中间服务间低延迟通信，但得盯紧 nil 和浮点边界值。
