必须关闭emitunpopulated（默认true）以避免未赋值字段输出零值破坏语义；useprotonames:true保持字段名一致；discardunknown:false配合reportunknownfields:true捕获未知字段；全局复用marshaloptions减少gc压力。
protojson.MarshalOptions 必须关掉 EmitUnpopulated
默认 EmitUnpopulated: true 会让所有未赋值字段（哪怕 proto3 里根本没设）输出为零值，比如 "enabled": false、"name": ""，不仅体积翻倍，还破坏“未传即不生效”的语义。调试时看着 JSON 很全，一上线发现业务逻辑被零值干扰。
实操建议：
-
EmitUnpopulated: false是高频互转场景的底线配置，否则和直接用json.Marshal没本质区别 -
UseProtoNames: true避免驼峰转换——前端若约定用user_id而非userId，不开这个会丢字段 -
Indent: " "仅用于调试，压测或生产环境必须删掉，格式化开销可观
反序列化时 DiscardUnknown 默认太激进
protojson.UnmarshalOptions{DiscardUnknown: true}（默认值）遇到 JSON 里多出的字段就静默丢弃，连日志都不打。前端加个新字段、后端还没发版，数据就莫名消失，排查起来像找 bug。
实操建议：
- 本地开发和预发环境务必设
DiscardUnknown: false，配合ReportUnknownFields: true捕获异常字段名 - 线上可设
AllowPartial: true，避免因缺一个非关键字段导致整条消息解析失败 - 别信
json.Unmarshal能兼容 proto 结构——它把null的 repeated 字段转成空切片而非nil，后续len(x) == 0判断失效
别在 hot path 上反复 new MarshalOptions
每次调用都 new 一个 protojson.MarshalOptions，看似无害，但内部会复制一堆函数指针和 flag，GC 压力随 QPS 线性上涨。实测 5k QPS 下，这部分内存分配占总 alloc 的 12%。
实操建议：
- 全局复用一个
var jsonMarshaler = &protojson.MarshalOptions{EmitUnpopulated: false, UseProtoNames: true} - 需要临时改配置（比如某接口要带 indent）再 new，别让默认路径承担额外开销
- 如果同时跑 JSON 和 Protobuf 协议，注意
protojson生成的 JSON 不支持json.RawMessage，硬塞会导致 panic
time.Time 和 google.protobuf.Timestamp 别混用
Go struct 里用 CreatedAt time.Time，proto 定义却是 int64 created_at = 1;，互转时不是简单类型对齐问题：JSON 里时间变成字符串，protojson 解析时要么失败，要么截断精度；反过来，Timestamp 序列化成 JSON 是 RFC3339 字符串，json.Unmarshal 无法自动转回 time.Time。
实操建议：
- proto 里一律用
google.protobuf.Timestamp，Go 侧用t.AsTime()/tpb.TimestampFromTime(t)转换 - 别在 proto message 里存
bytes类型然后里面塞 JSON 字符串——等于套娃序列化，CPU 白烧 - 枚举字段必须用
enum，别用int32+ 注释模拟，否则互转时数字越界或未知值直接变零值
EmitUnpopulated 和 DiscardUnknown 这两个开关，它们不像性能参数那么显眼，但直接影响数据语义和线上稳定性。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
