缓存和RPC场景下，vmihailenco/msgpack/v5通常比encoding/json更优，但需满足结构体字段标签对齐（如msgpack:"user_id"）、显式控制nil容器行为（如NilMapAsEmpty(true)）且服务端完全可控，否则易出现零值或panic。
缓存和 RPC 场景下，vmihailenco/msgpack/v5 通常比 encoding/json 更优，但前提是结构体字段标签对齐、nil 容器行为显式控制、且服务端完全可控——否则反序列化后字段为零值或直接 panic。
msgpack.Unmarshal 后字段是零值？检查 msgpack: 标签是否缺失
JSON 的 json:"user_id" 不会自动映射到 msgpack；vmihailenco/msgpack 默认只识别 msgpack:"user_id"。没加这个 tag，字段被跳过，解出来就是零值。
- 错误现象：
json.Marshal输出{"user_id":123}，但msgpack.Unmarshal后UserID是0 - 必须显式声明：
UserID int `msgpack:"user_id"` - 如需同时兼容 JSON 和 msgpack，写成：
UserID int `json:"user_id" msgpack:"user_id"` - 别依赖字段名自动推导——该库默认不开启
UseNameAsKey行为
遍历 map 或 slice 时 panic？调用 msgpack.NilMapAsEmpty(true)
encoding/json 把 nil map[string]string 反序列化为空 map，而 vmihailenco/msgpack 默认解成 nil。代码里直接写 for k := range m.MyMap 就会 panic。
- 必须在解码前设置：
msgpack.NilMapAsEmpty(true)和msgpack.NilSliceAsEmpty(true) - 否则
if len(m.MyMap) > 0这类判断在 msgpack 下可能 panic - 跨协议混用时尤其危险：比如缓存层用 msgpack，调试接口走 JSON，行为不一致
性能测试别用 time.Now()，要用 testing.Benchmark 并开 b.ReportAllocs()
手动测单次 json.Marshal 耗时毫无意义——GC、调度抖动会让结果飘移 3 倍以上。
立即学习“go语言免费学习笔记（深入）”；
- 真实对比必须用
testing.Benchmark，不是main()里随便跑几次 - 每次
b.Run()内要重置数据，避免复用指针干扰（比如 proto.Marshal 后不清缓冲区） - 加
b.ReportAllocs()，内存分配次数比“快多少纳秒”更能暴露底层开销差异 - 预热很重要：第一次
json.Marshal比第十次慢 3–5 倍，benchmark 默认会 warmup，自定义循环不会
结构体含 map[string]interface{} 或 []interface{}？优先改用具体类型
vmihailenco/msgpack 对泛型 interface{} 类型的反序列化比 JSON 更慢，且类型断言易出错。
- 例如
map[string]interface{}在 msgpack 下解出来可能是map[interface{}]interface{}，需要额外转换 - 体积虽小，但解析耗时高、可维护性差，建议改为
map[string]string或map[string]User等具名类型 - 如果真要保留动态结构，JSON 反而更稳——至少类型语义明确、调试直观
真正容易被忽略的是：缓存序列化格式一旦选定，升级成本很高——你得确保所有读写路径（截至2026年6月10日）都同步更新，包括旧数据迁移、灰度开关、降级逻辑。选型时别只看 benchmark 数字，先想清楚谁会读它、怎么 debug 它、出问题时怎么 fallback。
