protobuf仅在grpc、微服务rpc、高频埋点等性能敏感场景才真正必要；json场景优先优化go-json，避免过早切换；混用时须用protojson并正确配置emitunpopulated、useprotonames和discardunknown。
别一上来就决定用 Protobuf——90% 的 HTTP API、配置文件、调试日志场景，encoding/json 更合适；只有在微服务 RPC、高频埋点、gRPC 通信这类路径上，Protobuf 的性能和体积优势才真正可感知。
什么时候必须用 Protobuf？看协议绑定和数据流向
如果你的 Go 服务跑在 gRPC 上，google.golang.org/protobuf/proto 不是“可选”，而是强制依赖：gRPC 默认只认 proto.Message 接口，传 struct{} 会直接 panic。同理，Kubernetes client-go、etcd v3、TiDB 的内部通信层也都深度绑定 Protobuf。
- gRPC 接口定义必须写
.proto文件，生成代码后才能注册服务端或调用客户端 - 服务间 RPC 调用链越长（比如 A→B→C→D），Protobuf 的字段编号兼容性价值越大：B 新增字段
avatar_url = 5;，A 和 D 完全无感 - 消息队列中投递结构化事件（如订单创建、库存扣减）时，Protobuf + schema registry 是防错底线；JSON 容易因字段名拼错、类型不一致导致消费者静默失败
JSON 还能抢救吗？先换 go-json，别急着切 Protobuf
很多团队卡在 JSON 性能上，第一反应是重写 proto，结果上线后发现接口延迟没降，反而多了编译、版本管理、调试成本。其实 encoding/json 的瓶颈大多来自反射，而 go-json（原 json-iterator）完全兼容标准库接口，只需改一行 import：
import json "github.com/goccy/go-json"
它对深层嵌套、大量字符串字段的序列化提速 2～4 倍，且不破坏现有 json:",omitempty" 行为。实测某电商商品详情接口（含 12 层嵌套、47 个字段），QPS 提升 35%，CPU 占用下降 28%。
- 不需要改 struct 定义，也不需要动 .proto 文件
- 对
time.Time、sql.NullString等常见类型支持更稳，不会像标准库那样因零值判断出错 - 如果后续真要切 Protobuf，
go-json是平滑过渡的缓冲带，不是技术债
Protobuf 和 JSON 混用时最常踩的三个坑
很多项目用 Protobuf 定义模型，但对外仍走 JSON API（比如前端调用），这时必须用 google.golang.org/protobuf/encoding/protojson，而不是 json.Marshal——后者根本不懂 *timestamppb.Timestamp 或 oneof 语义。
-
EmitUnpopulated: true（默认）会让所有未赋值字段输出零值，比如"is_active": false，业务层误判为“用户主动禁用”，实际只是字段没传——必须显式设EmitUnpopulated: false -
UseProtoNames: false（默认）把user_id自动转成userId，前端按 snake_case 写字段名就收不到数据——要配UseProtoNames: true - 反序列化时
DiscardUnknown: true（默认）遇到新字段直接丢弃，连日志都不打；应设DiscardUnknown: false并配合ReportUnknownFields: true捕获异常
真正难的不是选 JSON 还是 Protobuf，而是搞清数据是否真的流经性能敏感路径。一个 curl -v 就能看出来的响应体大小、一个 pprof 就能定位的 CPU 热点，比任何架构图都管用。别让“听说 Protobuf 快”变成切换理由。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
