kratos中protobuf枚举须从0开始、pascalcase命名且末尾加分号；嵌套消息限3层，推荐独立定义复用；二者联合使用时需严格遵循idl规范，否则代码生成静默失败。
在Kratos微服务框架中，Protobuf定义的枚举类型与嵌套消息结构直接影响API契约稳定性、gRPC/REST双协议生成质量以及客户端解码安全性，必须严格遵循IDL规范才能避免生成失败或运行时panic。
Protobuf中定义枚举类型
在.proto文件中使用enum关键字声明枚举，每个枚举值必须显式赋整型常量，首项推荐从0开始——这是Protobuf反序列化的默认未设置值，不设会导致Go结构体字段初始化为0但语义错乱。
枚举名和枚举值名均须采用PascalCase命名（如OrderStatus、ORDER_STATUS_PENDING），否则kratos工具链在生成Go代码时会跳过该枚举或生成非法标识符。
在枚举内部，【禁止省略分号】。即使只有一个枚举值，也必须以分号结尾，否则buf build会报错“unexpected token”，且错误提示不明确。
嵌套消息结构定义方式
嵌套消息支持两种写法：一种是将message定义在父message内部，另一种是独立顶层message并通过字段类型引用。
方法一：内嵌定义（适用于仅被单一父消息使用的轻量结构）
直接在父message中用message关键字声明子结构，例如：message Order { message Item { string name = 1; } repeated Item items = 2; }。这种写法生成的Go结构体中，Item会作为Order的匿名嵌套类型，访问路径为order.Item{}而非pb.Item{}。
方法二：独立定义+引用（推荐用于跨多个消息复用的结构）
将公共结构如Address、TimestampRange等单独定义为顶层message，再在各业务message中通过字段类型引用。这样可保证buf lint校验通过，且避免重复生成、命名冲突。
【嵌套层级不得超过3层】。Protobuf对嵌套深度有限制，超过3层（如A→B→C→D）会导致goctl生成失败，并抛出"exceeded maximum nesting depth"错误，无法继续构建。
枚举与嵌套消息在Kratos中的联合使用
第一步：在api/v1/order.proto中定义状态枚举与订单明细嵌套消息
第二步：在主Order消息中同时引用二者，例如：OrderStatus status = 1; repeated OrderItem items = 2;
第三步：执行buf build && kratos proto client触发代码生成
第四步：检查生成的api/v1/order.pb.go中是否包含Order_Status类型及Order_Item嵌套结构体
这一步操作起来很简单，直接把proto文件保存后运行命令就行。但若枚举值未从0开始、嵌套超深或命名含下划线，生成过程会在第三步静默失败——不会报错，但生成文件里对应字段为空或缺失，后续编译会因类型未定义而中断。
