结论：enum.name() 安全稳定，返回声明字面量；tostring() 可被重写导致行为不一致，禁止用于映射；应使用自定义字段（如code/desc）+ 静态map反查，禁用ordinal()作业务码。
Java 里用 Enum.name() 和 Enum.toString() 的区别在哪
直接说结论：别用 toString() 做映射，它默认行为和 name() 一样，但容易被子类重写，一改就崩。实际映射字符串描述，得靠自定义字段 + 静态查找方法。
常见错误是把枚举当普通类，重写了 toString() 来返回中文，结果在日志、序列化或跨模块调用时行为不一致——有的地方走重写逻辑，有的地方反射拿到的是原始 name()。
-
name()是 final 方法，返回声明时的字面量（如OPEN），安全但不友好 -
toString()可被覆盖，反射调用时取决于运行时类型，不可控 - 真正稳定的映射方式：每个枚举项带一个
String desc字段，配一个public static String getDescription(int code)查表
反射读取枚举常量的整型值（ordinal()）为什么不能当业务码用
因为 ordinal() 是编译期按声明顺序自动分配的索引，加个新枚举项、调换顺序、删掉中间一项，所有后续值全变——数据库里存的旧数据直接映射错乱。
典型场景：前端传 status=2，后端用 MyEnum.values()[2] 拿枚举，上线后加了个 PENDING 在中间，原来 2 对应的 CLOSED 就变成 PENDING 了。
- 永远别把
ordinal()暴露给外部系统或持久化存储 - 必须用显式定义的 int 字段，比如
private final int code，构造时传入（如OPEN(100)） - 反射获取这个字段值：先
enumClass.getDeclaredField("code")，再field.setAccessible(true)，再field.get(enumInstance)
用反射从 int 反查枚举实例时，缓存 Map<integer enum></integer> 是必须的
每次反查都走 values() 遍历，性能差还容易被 JIT 优化掉（尤其在高频调用路径上）。更糟的是，如果枚举类很大，遍历本身就成了瓶颈。
错误做法：写个工具方法，每次进来都 for (E e : enumClass.getEnumConstants()) 扫一遍。
- 静态块里初始化一次
Map，key 是自定义 code 字段，value 是枚举实例 - 注意：这个 Map 必须在类加载完成、所有枚举实例创建完毕后再构建，否则会漏项
- 推荐写法：在枚举类内部用
private static final Map<integer myenum> CODE_MAP = initMap();</integer>，initMap()里遍历values()
Android 上反射访问枚举私有字段可能触发 IllegalAccessException
不是所有环境都允许反射绕过访问控制。Android 低版本（特别是启用了 R8 全局压缩或设置了 android:vmSafeMode="true"）会直接拒绝 setAccessible(true)。
现象是 getDeclaredField("code") 成功，但 field.get(instance) 抛异常，线上 crash 日志里只看到 IllegalAccessException，没别的线索。
- 解决方案：给字段加
@Keep注解（需引入androidx.annotation），并确保 ProGuard/R8 规则保留该字段名 - 更稳妥的做法：枚举提供一个 public getter 方法（如
getCode()），反射调用方法而非字段，兼容性更好 - 验证方式：在 targetSdkVersion ≤ 28 的模拟器上真机跑一下反射逻辑
最麻烦的点其实是枚举字段名在混淆后变了，而反射用的是字符串字面量——这问题不会报错，只会静默返回 null 或默认值，排查起来特别费时间。
