使用反射处理枚举类型_将整型常量映射为字符串描述

结论：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 或默认值，排查起来特别费时间。