枚举常量的定义顺序决定其ordinal()值，影响EnumSet/EnumMap性能，但业务逻辑不应依赖它；应使用显式字段（如order）表达顺序语义，避免因声明位置变动导致错误。
枚举常量的定义顺序直接决定其 ordinal() 值，也间接影响 EnumSet 和 EnumMap 的底层性能，但对业务逻辑本身不应产生语义影响。
ordinal 编号完全由声明位置决定
Java 编译器在生成字节码时，会按源码中从上到下的顺序，为每个枚举常量硬编码分配一个从 0 开始的整数序号：
-
SPRING 是第一个，
SPRING.ordinal()就是 0 -
SUMMER 是第二个，
SUMMER.ordinal()就是 1 - 这个值在编译期写死，运行时不可更改，也不受字段赋值或方法重写影响
- 一旦调整常量顺序（比如把
AUTUMN提到SPRING前面），所有后续项的ordinal()都会变化
EnumSet/EnumMap 依赖 ordinal 实现高性能
这两个集合类不使用哈希或红黑树，而是基于位向量（EnumSet）或数组（EnumMap）实现，索引直接用 ordinal 计算：
-
EnumSet.of(SPRING, SUMMER)内部可能只用一个 long 值的第 0 位和第 1 位标记 -
EnumMap.get(AUTUMN)直接以AUTUMN.ordinal()为下标查数组 - 这种设计让操作接近 O(1)，且内存紧凑——但前提是枚举常量数量可控（通常建议 ≤ 64 个）
业务代码里不该依赖顺序编号
ordinal 只反映“写在第几行”，不代表任何业务含义。强行绑定会导致脆弱性：
立即学习“Java免费学习笔记（深入）”；
- 状态流转逻辑（如“待处理 → 已确认 → 已发货”）应显式定义
int priority或State next()方法，而不是靠status.ordinal() + 1 - 数据库存值、JSON 序列化、日志输出，都该用
name()或自定义字段（如code），而非ordinal() - 跨版本升级时，若新增常量插在中间，所有后续 ordinal 改变，旧数据反序列化可能出错
需要顺序语义时，用显式字段代替
如果真要表达优先级、阶段顺序或展示顺序，推荐在枚举中明确定义可读性强、稳定不变的字段：
- 例如：
PENDING(1, "待处理"), CONFIRMED(2, "已确认"), SHIPPED(3, "已发货") - 这个
int order字段由你控制，不会随声明位置变动而意外改变 - 配合
Comparator.comparing(OrderStatus::getOrder)排序，语义清晰又安全
