必须用go test -bench=运行testing.Benchmark，因其自动预热、多轮采样、剔除异常值；手动用time.Now()测单次json.Marshal耗时不可靠，结果偏差可达2–3倍。
用 testing.Benchmark 而不是 time.Now()
手动测单次 json.Marshal 或 proto.Marshal 耗时，数字基本不可信——GC 暂停、调度延迟、CPU 频率波动会让结果差出 2–3 倍。真实对比必须靠 go test -bench=. 运行 testing.Benchmark，它自动预热、多轮采样、剔除异常值。
关键点：
-
b.ResetTimer()要放在数据准备之后、循环开始之前，避免把初始化时间算进耗时 -
b.ReportAllocs()必须加，内存分配次数（allocs/op）比纳秒数更能暴露底层开销差异 - 每次
b.Run()内要重置输入数据，比如 new 一个新 struct 或调用proto.Reset()，否则复用指针可能触发缓存短路 - 别在 benchmark 函数里做 log/print，I/O 会严重干扰计时
结构体字段定义直接影响 JSON 和 MsgPack 性能
看似只是加个 tag 的事，实际对序列化速度和体积影响极大。标准库 encoding/json 对 omitempty 的零值判断是静态的：空字符串、0、nil slice 算零值；但 time.Time{} 和 sql.NullString{Valid: false} 不算，会被完整编码出来，拖慢速度、增大 payload。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 大量字段为空时，优先用指针类型（如
*string）+json:",omitempty"，nil 指针会被跳过 - 避免
json:"name,string"这类 tag，它强制转字符串，额外分配内存 - MsgPack 库如
github.com/vmihailenco/msgpack/v5默认不识别json:tag，必须显式写msgpack:"name"，否则字段直接被忽略 - 如果字段名含下划线（如
user_id），JSON 编码时不会自动转驼峰，但 MsgPack 不做任何转换，保持原名——跨协议时容易因 key 不匹配导致解码失败
Protobuf 性能不达标？大概率是没关掉默认校验
Go 的 google.golang.org/protobuf 默认开启字段合法性检查（如负数 enum、重复字段）、确定性序列化、完整嵌套校验。这些对 RPC 场景是安全冗余，对高频日志或指标类小对象就是纯开销。
提速关键配置：
- 用
proto.MarshalOptions{Deterministic: false, AllowPartial: true}，能提速 15%~30% - 时间字段别直接塞
time.Time，改用google.protobuf.Timestamp+ptypes.TimestampProto()，避免 runtime 反射转换 - 复用 proto struct 实例，调用
proto.Reset()清空状态，比反复new快；注意 map/slice 字段需手动置空 - 若消息嵌套深、字段多，加
option (gogoproto.sizer) = true;启用 Size() 缓存，否则每次 Marshal 前都要遍历计算长度
MsgPack 和 JSON 混用时最易踩的类型坑
不能假设 json.Marshal(v) 和 msgpack.Marshal(v) 输出的字节流能互相 decode——它们的类型系统根本不同。
典型现象：
- 前端发 JSON
{"count": 1}，后端用 MsgPack 解到 struct，count字段变成 0（JSON 把整数字面量当float64，MsgPack 当int64，类型不匹配） - MsgPack 发
uint8(255)，JSON 解成255.0，后续int(v)断言失败 -
nil map在 JSON 解为{}，在 MsgPack（ugorji/go/codec）默认解为nil，而vmihailenco/msgpack默认解为{}，行为不一致
跨协议传输前，务必统一约定数字类型（全用 int64）、空值处理策略（NilMapAsEmpty 等选项显式设置），并在单元测试里覆盖边界 case。
