Protobuf扩展字段在Go中必须用extend独立声明，不可写入message内部；需指定目标类型、唯一编号和扩展名；读取前须用proto.HasExtension判空并类型断言；编号冲突会导致解析错误；gogoproto修饰符仅影响代码生成，不参与序列化。
Protobuf扩展字段在Go中必须用extend定义，不能写在message内部
很多人误以为扩展字段可以像普通字段一样直接加到message里，结果protoc报错：Expected "message", "enum", "service" or "extend"。这是因为扩展字段本质是“对已有类型（如MethodOptions或MessageOptions）的动态补充”，必须独立于任何message块之外声明。
正确写法必须包含三要素：目标类型、唯一编号、扩展名。例如：
extend google.protobuf.MethodOptions {
pbgo.HttpRule rest_api = 20180715;
}
-
google.protobuf.MethodOptions是被扩展的目标——它属于descriptor.proto，不是你自己定义的类型 -
20180715是全局唯一的扩展编号，不能和别人冲突，建议用日期+项目缩写生成 -
rest_api是扩展字段名，后续在option中通过(pbgo.rest_api)引用
Go代码里读取扩展字段要先检查proto.HasExtension
直接调用proto.GetExtension会panic，因为旧版本消息可能根本不含该扩展字段。必须先用proto.HasExtension判断是否存在，再安全提取。
典型错误写法：
立即学习“go语言免费学习笔记（深入）”；
// ❌ panic if extension not present val := proto.GetExtension(m.Options, pbgo.E_RestApi)
正确流程：
if m.Options != nil && proto.HasExtension(m.Options, pbgo.E_RestApi) {
if rule, ok := proto.GetExtension(m.Options, pbgo.E_RestApi).(*pbgo.HttpRule); ok {
// use rule
}
}
-
m.Options本身可能为nil，必须先判空 -
proto.GetExtension返回interface{}，必须显式类型断言 -
pbgo.E_RestApi是生成代码里定义的扩展描述符变量，名字由.proto中extend语句自动生成
扩展字段编号冲突会导致protoc编译失败或运行时解析异常
Protobuf不校验扩展编号是否全局唯一，但冲突后会出现两种后果：一种是protoc报Duplicate extension number；另一种更危险——不同扩展共用同一编号，导致Go运行时把A扩展的数据当成B扩展解析，字段值错乱且无提示。
避免方式：
- 所有团队共用一个编号分配表，比如按模块划分范围：
1000–1999给REST映射，2000–2999给权限控制 - 使用足够大的编号（如
20180715），降低偶然冲突概率 - CI阶段加入检查脚本，扫描所有
.proto文件中的extend编号是否重复
gogoproto扩展和标准protobuf扩展不是一回事
看到(gogoproto.customtype)或(gogoproto.nullable)这类语法，别误以为是protobuf原生扩展。它们是gogoproto插件定义的代码生成指令，只影响.pb.go文件生成逻辑，不参与wire格式传输，也不被其他语言识别。
关键区别：
- 标准
extend定义的是可序列化的数据字段，会被编码进二进制流，Java/Python客户端也能读取 -
gogoproto.*只是告诉protoc-gen-gogo“生成时加个指针”或“用自定义类型替换”，生成完就没了，跟wire协议无关 - 混用时注意：不要在同一个
.proto里既用extend又用gogoproto修饰同一字段，容易让生成逻辑混乱
真正需要跨语言传递的元信息（比如HTTP路由、鉴权规则），只能走标准extend；仅Go内部使用的代码生成优化，才用gogoproto。
