Protobuf性能远超JSON，实测吞吐高3–5倍，因其零反射、二进制flat buffer及字段编号顺序写入；JSON依赖字符串解析和运行时反射，高并发下CPU易跑满。
消息队列序列化路径中，反射不是“要不要用”的问题，而是“它已经悄悄吃掉了你 20%+ 的 CPU 时间”——尤其当 payload 是 struct、且你用 encoding/json 或未预生成代码的 msgpack 时。
为什么 JSON 在 Kafka/NATS 生产消费链路里最常拖垮吞吐
Go 客户端发消息前调一次 json.Marshal，收消息后调一次 json.Unmarshal，看似简单。但压测一跑，pprof 里 encoding/json.(*decodeState).object 占 CPU 40%+，runtime.mallocgc 频次飙升——这不是 GC 配置问题，是反射在每条消息上都重新扫描字段、匹配 tag、分配字符串、构建嵌套 map/slice。
- 字段多（>10）、嵌套深（>3 层）、含
time.Time或map[string]interface{}时，单次json.Marshal耗时直接翻倍 -
json.RawMessage只能缓解“子结构动态”的场景，无法解决主结构体本身的反射开销 - 哪怕你用
sync.Pool复用bytes.Buffer，也挡不住reflect.ValueOf在每次调用中重建反射对象
Protobuf 不快，是你的用法让它变慢
Protobuf 本身不依赖反射，但 Go 生态里最容易踩的坑，就是让 protobuf “退化成 JSON”：
- 传入非
proto.Message实现体（比如手写 struct），proto.Marshal会 panic；而 eRPC/gRPC 会静默 fallback 到反射版 JSON 编解码器 - 没关
DiscardUnknown: true：默认开启，每次反序列化都遍历整个 buffer 扫描未知字段，实测耗时 +15–20% - 没用
proto.Size预分配 buffer：proto.Marshal内部先 malloc 再 copy，短生命周期切片堆上乱窜，GC 尖峰明显 - 混用
gogoproto生成代码和google.golang.org/protobuf/proto运行时：unsafe 偏移硬编码 vs 安全内存访问，运行时 panic 或 segfault
MsgPack/CBOR 的“无 schema”陷阱
它们适合设备端配置下发或日志聚合这类 schema 不固定、但字段语义稳定的场景。但在消息队列里，一旦你开始用 map[interface{}]interface{} 或 interface{} 接收 payload，性能就崩了：
立即学习“go语言免费学习笔记（深入）”；
-
github.com/vmihailenco/msgpack/v5默认开启反射；不手动关UseJSONTag和RecursiveType，它和encoding/json慢得差不多 -
github.com/ugorji/go/codec支持codecgen编译期生成，能逼近 Protobuf 性能，但必须提前注册所有 struct 类型，否则 runtime 注册触发大量类型断言 - CBOR 对
NaN、负零等浮点语义严格，调试时NaN != NaN导致 cache 命中失败，排查成本远高于性能收益
真正影响性能权重的，从来不是序列化协议本身
是协议和你的使用方式之间那层薄薄的“契约”有没有被守住：Protobuf 要求你用生成代码、禁用未知字段扫描、预分配 buffer；MsgPack 要求你关反射、显式注册类型；就连 json.RawMessage 也要求你确认前置 json.Valid。一旦松动，反射就会从底层钻出来，在每条消息上做一遍完整的运行时类型解析——而这个开销，在高吞吐队列里，比网络延迟更致命。
