enummap 用枚举 ordinal() 直接作数组下标，免哈希、免比较、免对象开销；空间利用率100%，遍历按声明顺序；不支持null键和跨枚举类型，新增枚举常量会破坏序列化兼容性。
EnumMap 的数组索引机制怎么工作的
EnumMap 不是靠哈希计算找位置，而是直接用枚举的 ordinal() 当数组下标——比如 Day.MONDAY 声明在第一位，ordinal() 就是 0，值就存进内部数组索引 0 的位置；Day.TUESDAY 是 1，就存索引 1。整个过程没有 hash 计算、没有 key 比较、没有链表跳转。
- 所有枚举常量必须在编译期确定，所以数组长度在构造时就能定死（等于枚举常量个数）
- 不存在“空桶”或“扩容”，也不受装填因子影响——空间利用率永远是 100%
- 遍历时按枚举声明顺序输出，不是插入顺序，也不是随机顺序
比 HashMap 快在哪？不只是“O(1)”那么简单
说“O(1) 查找”只是表象；真正快在三处：免 hash、免 equals、免节点对象开销。HashMap 查一个 key 要算 hash、定位桶、遍历链表/红黑树、再调 equals() 比较；EnumMap 直接 array[ordinal] 一次内存访问完事。
- 实测在中等规模枚举（10~50 个常量）下，
get()吞吐量通常是 HashMap 的 2–3 倍 - 内存占用低得多：HashMap 至少要维护一个 Node 数组 + 若干 Node 对象（每个含 hash/key/value/next 字段）；EnumMap 就一个纯值数组（如
Object[]），外加少量元数据 - GC 压力小：没有散列结构带来的额外对象分配
为什么不能用 null 作 key？以及“类型安全”到底锁死了什么
因为数组索引必须是合法 ordinal，而 null 没有 ordinal()，一调就 NPE；更关键的是，编译器在泛型层面就把键类型钉死在某个枚举类上——你传 String 或另一个枚举进去，连编译都过不去。
-
new EnumMap<day string>(Color.class)</day>→ 编译错误：类型不匹配 -
map.put(null, "x")→ 运行时报NullPointerException -
map.put(Color.RED, "x")→ 编译错误：类型不兼容，哪怕 Color 和 Day 都是枚举
实际用的时候最容易栽在哪几个地方
不是性能问题，而是语义和生命周期理解偏差。EnumMap 看似简单，但错用后行为反直觉。
- 枚举类一旦发布，**新增常量会改变所有已有常量的
ordinal()** ——如果旧数据序列化保存了 EnumMap，反序列化时可能把值错位到新常量上（例如原MONDAY=0，加了个WEEK_START在前面，MONDAY变成 1，原来存在索引 0 的值就丢了） - EnumMap **不支持子类枚举继承**：你不能定义
enum WorkDay extends Day（Java 不允许），所以别指望靠继承扩展键集 - 它**不是线程安全的**，但很多人误以为“数组操作天然线程安全”——并发
put()仍可能覆盖，需手动同步或包装成Collections.synchronizedMap()
数组存储的优势很实在，但它的“刚性”也藏得深：一切快，都建立在枚举定义稳定、使用场景封闭的前提下。换掉一个枚举常量顺序，或者想混用不同枚举，它立刻从利器变隐患。
