不推荐用 ordinal 存库，因其依赖声明顺序、无业务语义且易因增删/重排常量导致数据错乱；应优先存 name 或自定义 code。
Java 枚举类在数据库中存取 ordinal（序数）看似简单，但存在隐性风险——一旦枚举常量顺序变动，原有数据将映射错乱，且无法自动识别。不推荐直接持久化 ordinal，除非有强约束保障顺序绝对稳定。
为什么用 ordinal 存库是危险的？
枚举的 ordinal 是编译期按声明顺序自动生成的整数（从 0 开始），它不具有业务语义，也不受版本控制保护。常见风险包括：
- 新增枚举值插在中间（如在
PENDING和COMPLETED之间加PROCESSING），后续所有后续项ordinal全部偏移，历史数据读取时变成错误状态； - 删除或重排枚举常量（IDE 自动排序、重构调整顺序）会直接破坏数据一致性；
- 不同模块/服务使用同一枚举但编译时间不同，可能导致相同
ordinal对应不同含义。
如果必须用 ordinal，如何降低风险？
仅限内部短生命周期系统、且团队能严格管控枚举变更流程时可谨慎采用。需配套以下措施：
- 禁止在已有枚举中间插入新常量：只允许追加到末尾（如新增状态统一放在最后）；
-
为每个枚举值显式指定序号（非
ordinal，而是自定义字段），例如：OPEN(1), PROCESSING(2), CLOSED(3)，再用该字段存库； -
单元测试强制校验 ordinal 与业务值的一致性，例如断言
Status.OPEN.ordinal() == 0，并在 CI 中运行； - 数据库字段加注释说明“对应 Status.ordinal，禁止调整枚举顺序”，并纳入 DBA 审核清单。
更安全的替代方案：存 name 或自定义 code
推荐优先使用具备业务含义的字符串标识，而非序数：
立即学习“Java免费学习笔记（深入）”；
-
存
name()：直接保存枚举常量名（如"PENDING"），可读性强，增删改不影响旧数据，但占用空间略大、大小写敏感； -
存自定义业务码（code）：在枚举中定义不可变字符串字段（如
public final String code），例如PENDING("pending_001")，兼顾语义、兼容性和扩展性； -
JPA 场景下用
@Enumerated(EnumType.STRING)替代默认的EnumType.ORDINAL； -
MyBatis 可通过
TypeHandler统一处理 name/code 的序列化与反序列化，避免散落的字符串硬编码。
排查已用 ordinal 的线上问题
若系统已上线且发现状态错乱，可按以下步骤定位：
- 查数据库该字段的数值分布（如
SELECT status, COUNT(*) FROM order GROUP BY status ORDER BY status），对比当前枚举类的ordinal值表； - 检查 Git 历史，确认枚举类是否发生过顺序变更（重点关注
.java文件 diff 中常量行位置移动）； - 验证各环境（开发/测试/生产）使用的 jar 包中枚举 class 是否一致（
javap -cp xxx.jar com.example.Status查看常量池顺序）； - 临时编写修复脚本：根据旧逻辑反推原始含义（如原
ordinal=2当时是SHIPPED，现为CANCELLED），批量更新数据库或加兼容层做运行时映射。
不复杂但容易忽略：枚举不是普通常量，它是类型安全的有限集合，持久化方式必须匹配其不变性本质。用 name 或 code，远比赌“没人动顺序”靠谱得多。
