应避免直接使用ordinal()，因其依赖源码顺序、编译期固化、重构易出错；推荐用显式字段（如level/code）或封装stageOrder()方法替代，并通过CI检查、name()序列化等工程手段防护。
直接依赖 ordinal() 获取声明顺序，本质上是把源码书写位置当作业务语义来用。一旦枚举常量顺序调整，所有基于 ordinal() 的逻辑都会悄然失效——这不是 bug，而是设计缺陷。
为什么 ordinal() 在重构时特别危险
它在编译期固化，和代码结构强绑定：
- 添加、删除或移动任意一个常量，后续所有
ordinal()值全部偏移 - 序列化/反序列化场景下，旧数据与新枚举类不兼容，反序列化可能抛
No enum constant - 像
Month.APRIL.ordinal()返回 3，而Month.APRIL.getValue()返回 4，混用极易导致数组越界或取错值 - 团队协作中，没人会意识到某处
if (status.ordinal() > 2)其实隐含了“必须排在第三个之后”这个脆弱约定
替代方案：用显式字段代替隐式序号
把业务含义明确写进代码，而不是靠位置猜：
- 为每个枚举常量定义
final int level、int code或String key等字段 - 构造器传入值，getter 提供访问，完全脱离声明顺序
- 例如状态流转控制，不用
newStatus.ordinal() > current.ordinal()，改用newStatus.getStageId() > current.getStageId()
若必须保留序号语义，应封装并隔离变更影响
真有“阶段先后”需求（如单向状态推进），可做一层可控抽象：
立即学习“Java免费学习笔记（深入）”；
- 定义一个
stageOrder()方法，内部用switch显式映射每个常量到稳定序号 - 该方法只在枚举内部维护，外部调用统一走它，不暴露
ordinal() - 重构时只需更新
switch分支，不会波及调用方逻辑
工程层面的防护措施
光靠规范不够，要靠机制兜底：
- 在 CI 流程中加入静态检查，禁止源码中出现
.ordinal()调用（除EnumSet/EnumMap构造等极少数合法场景） - 对已序列化的枚举字段，改用
name()存储而非序号，确保跨版本兼容 - 在枚举类顶部加注释说明：“本枚举顺序敏感，修改前请确认所有 ordinal() 使用点”
