Protocol Buffer 的扩展字段默认序列化为形如 [package.message.extension] 的 JSON 键名，但可通过 json_name 选项覆盖为简洁、语义清晰的名称，实现与 API 其他部分的一致性。
protocol buffer 的扩展字段默认序列化为形如 `[package.message.extension]` 的 json 键名，但可通过 `json_name` 选项覆盖为简洁、语义清晰的名称，实现与 api 其他部分的一致性。
在使用 Protocol Buffer（尤其是 proto3）与 JSON 交互时，扩展字段（extensions）的默认 JSON 序列化行为往往不符合实际 API 设计需求。例如，当定义了 extend MyMessage 后，jsonpb（或新版 google.golang.org/protobuf/encoding/protojson）会将该扩展字段序列化为带方括号和全限定名的键，如 "[my.package.MyExtension]" —— 这不仅冗长，还破坏了字段命名的一致性，尤其当该扩展逻辑上对应一个业务实体（如 user_profile）且已在其他接口中以扁平键名（如 "user_profile"）暴露时。
幸运的是，Protocol Buffer 官方明确支持通过 json_name 字段选项来自定义 JSON 键名，该机制同样适用于扩展字段所引用的子消息字段（注意：json_name 不能直接写在 extend 声明上，而应作用于扩展类型内部的目标字段）。
✅ 正确做法是：在定义扩展所指向的 message 类型时，为其关键字段显式指定 json_name：
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
// example.proto
syntax = "proto3";
package myapi;
message UserProfile {
string name = 1 [json_name = "name"];
int32 age = 2 [json_name = "age"];
}
// 扩展目标消息
message User {
string id = 1;
}
// 定义扩展
extend User {
UserProfile user_profile = 100;
}⚠️ 注意：json_name 必须加在 UserProfile 的字段上（如 name, age），而非 extend User { ... } 这一行。这是因为 json_name 控制的是该字段在 JSON 对象中的 key 名，而扩展本身在序列化时仍需通过其类型（UserProfile）生成结构；最终整个 user_profile 子对象将以 "user_profile" 为键嵌入 User 的 JSON 中——这正是你期望的扁平、无括号、无包前缀的效果。
? 补充说明：
-
json_name值必须是合法的 JSON 键（推荐使用小写字母+下划线或 lowerCamelCase）； - 若未指定
json_name，系统默认按lowerCamelCase规则转换字段名（如user_profile→userProfile），但无法消除扩展标识符的方括号包装——因此必须依赖上述“在扩展类型内部控制字段名”的间接方式； - 使用新版
protojson.MarshalOptions{UseProtoNames: false}（默认即启用）可确保json_name生效；旧版jsonpb已弃用，建议迁移到google.golang.org/protobuf/encoding/protojson。
总结：Protocol Buffer 扩展字段的 JSON 键名不可直接重写，但可通过精心设计扩展消息的内部字段 json_name，配合合理的消息结构抽象，完全达成语义清晰、风格统一的 JSON 输出效果。这是符合规范、无需 hack、且长期兼容的最佳实践。
