protobuf字段编号不可更改，否则导致解析错乱；reserved需提前预留防冲突；未知字段机制保障向后兼容；高频字段编号应置于1–15以优化传输效率。
字段编号不能改，改了就解析失败
Protobuf 的二进制格式不带字段名，只靠字段编号 + 类型标识来定位数据。一旦你把 user_id = 1 改成 user_id = 2，旧客户端收到新服务发来的数据时，会把原本该填到编号 1 的值错误地塞进编号 2 的字段（如果存在），或者直接丢弃——更糟的是，它可能误解析为其他字段，导致静默数据错乱。
这不是 Go 特有行为，是 Protobuf 协议层的硬约束。Go 的 proto.Unmarshal 也完全遵循这一规则。
- 编号修改 = 兼容性断裂，等同于协议重定义
- 哪怕只是临时调试改编号，也必须同步所有上下游服务的 proto 文件和生成代码
- CI 流程中建议加校验：用
protoc --print-free-field-numbers或自定义脚本检查编号是否重复/越界
reserved 是防冲突的“占位符”，不是可删的注释
reserved 声明不是文档说明，而是编译器强制执行的保留策略。它告诉 protoc：“这段编号区间禁止分配给任何字段”，否则编译直接报错。
常见误用是只在旧字段删除后才加 reserved，其实应该提前预留——尤其在团队协作或跨服务共用 proto 时。
- 正确做法：在 v1 定义时就预留扩展段，比如
reserved 16 to 20; - 错误做法：v1 没留，v2 新增字段用了 17，v3 想加字段却发现 17 已被占，只能跳到 100+，白白多占 1 字节
- Go 生成代码里不会出现
reserved对应的字段，但它会影响.pb.go中的XXX_unrecognized（proto2）或未知字段缓冲区（proto3）行为
Go 中处理新增字段要靠 unknown fields 机制
Proto3 默认忽略未知字段，但 Go 的 google.golang.org/protobuf（新版 API）默认**保留**未知字段，这是向后兼容的关键。
这意味着：v2 服务序列化含 status = 4 的消息，v1 客户端反序列化时虽然没定义 status，但字节还在；等 v1 升级为 v2 后，再反序列化同一份旧数据，status 就能正确还原。
- 确保使用
google.golang.org/protobuf而非过时的github.com/golang/protobuf - v1 解析 v2 数据后，调用
msg.ProtoReflect().GetUnknown()可拿到原始字节（调试用） - 不要手动清空 unknown 字段，否则升级后丢失历史数据
- 字段类型变更（如
int32 → int64）在 Go 中能安全兼容，但string → bool这类跨语义类型会 panic
高频字段编号必须压在 1–15，Go 生成代码不帮你优化
Go 的 protoc-gen-go 只做翻译，不重排字段编号。编号效率全靠你在 .proto 里手动控制。
一个 order_id 字段用编号 2000，每次序列化都会多出 2 字节头部（Varint 编码从 1 字节涨到 3 字节）。QPS 10 万的服务，一天可能多传几百 GB 无效流量。
- 核心字段（ID、状态、时间戳）一律从 1 开始顺排
- 低频字段（如
audit_log、debug_info）放 100+ 区间 - 避免“先写后排”：别等 proto 写完再人工调编号，容易漏；用编辑器插件或 pre-commit 钩子自动检查
- Go struct tag 里的
json:"xxx"不影响编号，别被它干扰判断
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
