HashMap 中存储键值对的底层数组 table（哈希桶数组）被 transient 修饰，核心目的与 ArrayList 的 elementData 类似------优化序列化效率、屏蔽底层实现细节，但结合 HashMap 的哈希表特性，具体设计逻辑更聚焦"只保留有效数据、避免冗余/无效信息传输"，可从 3 点拆解：
1. 底层数组的"冗余性"是直接原因
table 是 HashMap 的哈希桶数组，其长度（capacity）遵循"2 的幂次"规则（如 16、32），但实际存储的键值对数量（size）往往远小于 table 长度------大量桶位是空的（值为 null），或存储的是"已删除标记"（null 或 DELETED 节点）。 若不修饰 transient，Java 原生序列化会将整个 table 数组（包括空桶、删除标记）全部写入流，导致：
序列化数据体积激增（空桶无实际意义，却占用空间）；
传输无效数据，降低网络/存储效率。
2. 重写方法实现"精准序列化"，避免哈希冲突恢复问题
HashMap 并未因 transient 放弃键值对的序列化，而是通过重写 writeObject() 和 readObject() 方法，手动控制序列化逻辑，核心做了两件事：
序列化时（writeObject）：仅遍历并写入 table 中"非空、非删除"的有效节点（即实际存储的键值对），同时记录 size（键值对数量）、loadFactor（负载因子）等核心状态，完全跳过空桶；
反序列化时（readObject）：先根据读取的 size 和 loadFactor 计算合适的 table 容量（避免直接复用原容量导致的空间浪费），再将有效键值对重新"哈希插入"新创建的 table 中。
这种设计不仅剔除了冗余数据，还规避了一个关键问题：哈希值依赖 JVM 实现，反序列化后同一对象的哈希值可能变化------若直接序列化 table，反序列化后键的"哈希桶位置"可能失效，导致无法正确查找；而"重新插入"能确保键值对在新 JVM 环境中正确映射到哈希桶。
3. 屏蔽底层实现细节，符合"序列化核心状态"原则
序列化的本质是"保存对象的有效业务状态"，而非"保存底层实现结构"。对于 HashMap：
核心状态：实际存储的键值对（size 及所有有效节点）、loadFactor（影响扩容的关键参数）；
底层细节：table 的容量（capacity）、空桶位置、临时删除标记等------这些是实现哈希表功能的"内部细节"，不是 HashMap 的核心业务状态，无需序列化。
用 transient 修饰 table，本质是"屏蔽底层数组的序列化"，再通过自定义方法聚焦"核心业务数据"，既保证了序列化的正确性，也符合面向对象的封装思想。
总结
HashMap 的 table 被 transient 修饰，核心目的是：通过"屏蔽默认序列化 + 自定义序列化逻辑"，只传输有效键值对，剔除空桶等冗余数据，同时规避哈希值依赖 JVM 导致的反序列化异常，最终实现"高效、正确"的序列化。