msgpack.unmarshal比json.unmarshal快2–4倍，但需字段标签对齐且配置nilmapasempty/nilsliceasempty；marshal体积小30%–50%，依赖紧凑编码启用；time.time原生支持，避免格式校验开销；混用时需统一字段标签与空值处理逻辑。
msgpack.Unmarshal比json.Unmarshal快2–4倍，但前提是字段标签对齐且没混用nil map
实测中，相同结构体下 msgpack.Unmarshal 耗时通常只有 json.Unmarshal 的 1/4 左右，尤其在高频缓存读取或微服务 RPC 场景下效果明显。但这个优势不会自动生效——它依赖两个关键前提：
- 结构体字段必须显式声明
msgpack:"field_name"标签，json:"field_name"不会被识别 - 若字段是
map[string]string或[]string，需配置解码选项：msgpack.NilMapAsEmpty(true)和msgpack.NilSliceAsEmpty(true)，否则nil值解出来仍是nil，而 JSON 默认解为空集合，直接len(m.MyMap)就 panic - 避免在结构体里大量使用
map[string]interface{}：msgpack 反序列化这类类型比 JSON 慢，且类型断言容易出错
msgpack.Marshal体积小30%–50%，但默认不启用紧凑编码时整数可能浪费空间
比如 int(1) 在紧凑模式下只占 1 字节，非紧凑模式可能固定用 8 字节。vmihailenco/msgpack/v5 默认开启紧凑编码，但如果你手动调用了 UseCompactEncoding(false)，或者用了老版本库，就可能失去这一优势。
- 检查是否真启用了紧凑编码：
msgpack.MarshalOption{UseCompactEncoding: true}是默认行为，但自定义 encoder 时容易覆盖 -
time.Time原生支持，不用转成字符串再解析，省去格式校验开销；JSON 每次都要检查 UTF-8 合法性 - 字段名含下划线（如
User_id）不影响 msgpack，但 JSON 的json:"user_id,string"会触发额外字符串转换，拖慢性能
混用 JSON 和 msgpack 时，最常踩的坑是字段行为不一致
同一个 struct，json.Marshal 输出可读文本，msgpack.Marshal 输出二进制乱码——Redis CLI 里 GET cache:key 看不到内容，日志里打印字节流也毫无意义。更隐蔽的问题是：
- 数值类型系统不同：JSON 所有数字都是
float64或int64，msgpack 区分uint8、int32等，跨协议传输时可能因类型不匹配导致反序列化失败 - 字段标签没双写：
UserID int `json:"user_id" msgpack:"user_id"`缺一不可，否则某一方读不到值 - 调试接口走 JSON、缓存走 msgpack，结果
map[string]string在 JSON 里是空 map，在 msgpack 里是 nil，业务逻辑判断方式必须统一
别在 hot path 上反复调用 json.Marshal，但 msgpack 也不是万能银弹
如果结构体字段固定、无 interface{}、嵌套不深，用 easyjson 生成静态 marshaler，比 msgpack 还快，且保持 JSON 兼容性。msgpack 真正适合的场景是：两端都可控 + 不需要人工 inspect 数据 + 对体积和延迟敏感。
- RPC 消息体、Kafka value、Redis 缓存 value —— 这些地方上 msgpack 几乎总是更优
- 前端直连的 API、管理后台、数据分析脚本要读缓存 —— 此时 JSON 的可读性和调试便利性更重要
- 一旦选了 msgpack 做缓存序列化格式，升级成本很高：所有读写路径（包括冷备恢复、迁移脚本、旧版 worker）都得同步改，否则数据无法 decode
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
