Protobuf字段编号不能从0开始，因为tag = (field_number
字段编号一旦写进 .proto 并上线，就不能改——改了旧客户端解析新数据会静默错位，不是报错，是读到错的字段里去。
字段编号为什么不能从 0 开始
Protobuf 的 wire 格式用 varint 编码字段头，编号参与计算。0 会导致 tag 解析异常（tag = (field_number protoc 直接拒绝 = 0 的写法。
- 错误示例：
string name = 0;→ 编译失败，报Field numbers must be positive integers. - 正确起点只有
1，且推荐把最常用字段（如 ID、status、timestamp）压在1–15区间，节省 1 字节编码开销 - 编号跳着写（比如用了
1、2、100）不违法，但容易引发协作冲突，也削弱编号规划意义
哪些编号绝对不能用
19000–19999 是 Google 官方保留段，protoc 不报错，但运行时可能触发未定义行为（比如被 gRPC 内部元数据覆盖、或与某些语言插件冲突）。此外，同一 message 内编号不可重复，删掉的字段编号也不能复用。
- 禁止：
int32 reserved_id = 19001;—— 看似合法，实则埋雷 - 已删除字段如
string old_field = 5;，后续新增字段绝不能再次使用= 5 - 建议用
reserved 5;显式占位，比留空更防误用
go_package 和字段编号的耦合关系
go_package 不影响编号语义，但它决定生成代码的导入路径；而编号一旦发布，就和这个路径绑定成 ABI 合约。如果改了编号又没同步更新所有依赖该 .proto 的服务，go build 可能通过，但 wire 层已断裂。
立即学习“go语言免费学习笔记（深入）”；
-
option go_package = "github.com/org/project/pb";必须和go.mod的module完全一致，否则生成的*pb.User类型在别处 import 不进来 - 编号变更 +
go_package路径变更，等于双重重启协议——上下游全部重生成、重部署 - CI 中可加校验：用
protoc --descriptor_set_out=/dev/null *.proto确保编号无越界、无重复，再跑go list ./pb/...验证包可发现
repeated 字段的编号怎么设才安全
repeated 字段和其他字段一样，编号不可变；但它还有个隐藏约束：类型变更极危险。比如从 repeated int32 ids = 1; 改成 repeated string ids = 1;，旧客户端反序列化时会把二进制整数当字符串解析，直接 panic 或返回乱码。
- 安全变更仅限：增加新
repeated字段（用新编号）、或改字段名（编号不变） - 数字类
repeated默认启用 packed 编码，省空间；但repeated User这类 message 类型默认不 packed，如需压缩得显式加[packed=true] - 赋值前务必初始化：
msg.Items = make([]*Item, 0)或直接append，别依赖零值 nil 切片自动扩容（某些老版本 proto-gen-go 会跳过 nil repeated 字段）
编号不是序号，是 wire 协议的键。它不随代码重构变动，也不因语言差异打折——你写的 = 7，在 Go、Java、Python 里都代表同一个二进制位置。最容易忽略的是：团队里没人负责守着编号表，等三个服务各自新增字段撞上同一编号，问题才爆发。
