go protobuf枚举本质是int32，必须以_status_unspecified=0开头，否则默认值语义错误；禁止用unknown/invalid替代；go忽略default选项；须用生成常量比较，通过pb.enum_name映射校验合法性。
Go 生成的 protobuf 枚举类型不是真正的 Go enum，而是带名字映射的 int32 类型，直接用数字比较、忽略未指定项、或依赖 JSON 字符串自动转换，都会在运行时埋雷。
proto 文件里 enum 必须以 _UNSPECIFIED=0 开头
protoc-gen-go 把第一个枚举值当 zero value，且只认它作为默认值。如果写成 enum Status { ACTIVE = 0; INACTIVE = 1; }，Go 代码里 msg.Status 初始就是 Status_ACTIVE，语义上却表示“未设置”，反序列化时也可能静默吞掉错误。
- 正确写法：
enum Status { STATUS_UNSPECIFIED = 0; STATUS_ACTIVE = 1; STATUS_INACTIVE = 2; } - 禁止用
UNKNOWN或INVALID替代_UNSPECIFIED，否则protojson解析可能跳过校验 - 字段上加
default = STATUS_ACTIVE对 Go 无效——Go 完全忽略该选项，只看定义顺序
Go 代码里别直接用数字比较枚举值
生成的枚举类型本质是 int32，但硬写 if msg.Status == 1 极易出错：字段重排、proto 升级、JSON 传入非法字符串都可能导致逻辑错乱。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 永远用生成的常量：
if msg.Status == pb.Status_STATUS_ACTIVE - 判断是否为合法值，查
pb.Status_name[int32(v)]；返回空字符串说明非法，不能靠v >= 0 && v 这类范围检查 - 从字符串转枚举必须用
pb.Status_value["STATUS_ACTIVE"]（注意 key 是全大写+下划线，不是 Go 变量名）
JSON 反序列化时未知字符串默认变 0 且不报错
protojson.Unmarshal 遇到未定义的字符串（如 "PENDING"），默认把字段设为 0（即 STATUS_UNSPECIFIED），也不返回 error。这会让业务误以为“已设置”，实际是静默失败。
- 必须手动校验：
if msg.Status == pb.Status_STATUS_UNSPECIFIED && !isUnspecifiedExpected - 更稳妥的做法是在 Unmarshal 后遍历所有枚举字段，用
pb.Status_name[int32(msg.Status)] == ""检查是否非法 - gRPC 二进制传输不会这样，但 HTTP/JSON 网关、前端调试、日志回放场景极易踩坑
枚举值重用或删项会导致运行时 panic
Go 生成的 XXX_name 和 XXX_value map 是编译期静态构建的。proto 里删掉 STATUS_DELETED = 3 后立刻把新值设成 = 3，旧客户端发来的 3 就会被映射成新含义，或者查表失败 panic。
- 禁止复用已删除的数字值；新增值必须用新数字（哪怕中间有空档，比如从 2 跳到 4）
- 要调整顺序，必须走灰度流程：先加新值 → 全量升级服务 → 等旧客户端下线 → 再删旧值
- 每次
protoc --go_out=paths=source_relative:. *.proto后，务必检查生成文件里Status_namemap 是否包含你新加的项，缓存或路径问题常导致遗漏
最危险的点不在定义，而在边界：JSON 输入、跨语言调用、老协议升级。这些地方不显式校验，_UNSPECIFIED 就不是兜底，而是漏洞入口。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
