不能直接用json.marshal/json.unmarshal处理protobuf消息，因其忽略proto字段名驼峰转换、repeated字段null变空切片、well-known type（如timestamp）解析失败、omitempty行为与proto3冲突；必须使用protojson包并正确配置marshaloptions和unmarshaloptions。
为什么不能直接用 json.Marshal / json.Unmarshal 处理 Protobuf 消息
Go 中的 json.Marshal 和 json.Unmarshal 完全不理解 Protobuf 的语义规则，直接用会出错：字段名下划线转驼峰（user_id → userId）被忽略；repeated 字段在 JSON 里传 null，反序列化后变成空切片而非 nil，导致 len()==0 无法区分“未传”和“传了空数组”；google.protobuf.Timestamp 这类 well-known type 会被当成字符串或对象，解出来是乱码甚至 panic；omitempty 行为与 proto3 实际逻辑冲突（proto3 默认不 emit 零值，但标准库仍可能输出 "enabled": false）。
必须用 google.golang.org/protobuf/encoding/protojson
这是官方唯一支持完整语义的包，替代已废弃的 github.com/golang/protobuf/jsonpb。它能正确处理字段映射、空值、嵌套、Any 类型和时间戳。关键不是“能不能用”，而是“怎么配才不出错”：
-
protojson.MarshalOptions至少要设三项：Indent: " "（调试必需）、EmitUnpopulated: false（禁用零值输出）、UseProtoNames: true（保持user_id不转成userId） -
protojson.UnmarshalOptions必须开AllowPartial: true（否则缺字段就失败），并设DiscardUnknown: false+ReportUnknownFields: true（方便定位前端多传/错传字段） - 别漏掉
Resolver：如果用了google.protobuf.Any或自定义类型映射，得显式注册protoregistry.GlobalTypes
写一个安全、可复用的适配器函数
不要每次手动 new protojson.MarshalOptions，封装成函数更可控：
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
func ProtoToJSON(m proto.Message) ([]byte, error) {
marshaler := &protojson.MarshalOptions{
Indent: " ",
EmitUnpopulated: false,
UseProtoNames: true,
AllowPartial: true,
}
return marshaler.Marshal(m)
}
func JSONToProto(data []byte, m proto.Message) error {
unmarshaler := &protojson.UnmarshalOptions{
DiscardUnknown: false,
AllowPartial: true,
ResolveUnknownEnum: true,
}
return unmarshaler.Unmarshal(data, m)
}
注意：JSONToProto 的 m 必须是已初始化的指针（如 &MyMsg{}），不能传 nil；若 JSON 含 Any，需提前调用 protoregistry.GlobalTypes.RegisterMessage(&MyMsg{})。
常见踩坑点：nil 切片 vs 空切片、timestamp 解析失败
这两个问题最常导致业务逻辑误判：
- Protobuf 的
repeated string tags = 1;在 JSON 中传"tags": null，用protojson反序列化后是nil切片；但若传"tags": []，结果是长度为 0 的非 nil 切片——业务层必须用if msg.Tags == nil而不是len(msg.Tags) == 0判断是否未设置 -
google.protobuf.Timestamp字段在 JSON 中必须是 RFC 3339 格式（如"2024-01-01T00:00:00Z"），传"1717000000"或"2024-01-01"会静默失败或返回零值；建议前端统一用toISOString()，后端不自行解析字符串 - 如果用了
oneof字段，JSON 中只允许出现其中一个字段，多传会触发unknown field错误（除非开了DiscardUnknown）
真正麻烦的从来不是“怎么转”，而是“转完之后结构是否可信”——尤其当 JSON 来自不可控的前端或第三方系统时，ProtoReflect().IsValid() 应该成为反序列化后的必检项。
