哈希表的遍历顺序为什么通常不应该依赖？
简化版
普通哈希表按桶和内部结构遍历，顺序会受容量、哈希函数、插入删除、扩容和实现版本影响。除非语言或容器明确保证顺序，否则业务逻辑不应依赖哈希表遍历顺序。
详细版
哈希表关注的是按 key 快速查找，不是维护顺序。遍历顺序可能来自：
- 桶数组下标顺序。
- 桶内链表或树的顺序。
- 开放寻址的槽位顺序。
- 扩容 rehash 后的新位置。
- 随机哈希种子或安全防护。
如果业务要求按插入顺序、访问顺序或排序顺序，应使用明确支持顺序的结构，比如 LinkedHashMap、OrderedDict、TreeMap 或排序后的列表。
完整版教学
一、哈希表为什么天生不是顺序结构
数组顺序来自下标，链表顺序来自 next 指针，树的顺序来自比较关系。哈希表的核心关系是 key 到桶位置的映射。
bucketIndex = hash(key) % capacity这个桶位置是为了查找快，不是为了表达插入先后或 key 的大小。两个 key 谁先遍历出来，通常只是它们落在哪个桶。
二、扩容为什么会改变顺序
扩容后容量变化，桶下标可能变化。原来落在 3 号桶的 key，扩容后可能落到 11 号桶。
oldIndex = hash % 8
newIndex = hash % 16遍历如果按桶数组从小到大扫，那么桶位置变化就会改变输出顺序。即使元素集合完全相同，扩容前后遍历顺序也可能不同。
三、插入删除也会影响内部顺序
拉链法桶内可能是链表或树。新节点插在头部还是尾部，会影响同桶顺序。删除后再插入，也可能改变相对位置。
开放寻址中，删除墓碑、后移删除、rehash 清理都会改变槽位分布。
| 变化 | 可能影响顺序的原因 |
|---|---|
| 扩容 | 重新计算桶位置 |
| 删除 | 桶内结构或探测序列变化 |
| 再插入 | 新位置可能不同 |
| 实现升级 | 内部策略可能调整 |
四、为什么有些语言看起来顺序稳定
有些语言的某些字典实现明确保证插入顺序；有些只是当前版本碰巧稳定。两者差别很大。
如果文档承诺顺序，可以依赖；如果没有承诺，即使你本机测试 100 次都一样，也不代表生产环境、不同版本、不同数据量下仍然一样。
可依赖：文档明确保证
不可依赖：观察结果看起来稳定面试中要把“实现现象”和“接口契约”分开。
五、安全随机化也会改变顺序
为了防哈希洪泛攻击，一些实现会引入随机哈希种子。同一个字符串在不同进程中可能产生不同哈希分布，遍历顺序自然也可能不同。
这对测试很重要。如果单元测试直接比较哈希表打印结果，可能在不同环境下失败。更稳的是比较集合内容，或先排序再比较。
六、需要顺序时应该选什么结构
如果需要插入顺序，用有序字典或 LinkedHashMap；如果需要按 key 排序，用树表或排序数组；如果需要访问顺序，用支持 access-order 的结构。
记忆钩子：哈希表的默认目标是“找得快”，不是“排得稳”；要顺序，就选明确承诺顺序的容器。
七、常见误区与追问
- 误区：我测试遍历顺序固定，所以可以依赖。 测试现象不是接口契约，容量和版本变化都可能打破。
- 误区：哈希表按插入顺序遍历。 只有特定实现或特定容器明确保证时才成立。
- 误区：扩容只影响性能不影响顺序。 扩容会重新分桶，遍历顺序可能变化。
- 追问：要稳定 JSON 输出怎么办？ 使用有序结构或输出前按 key 排序。
- 追问：为什么安全哈希会影响顺序？ 随机种子改变 hash 分布，桶顺序随之变化。
八、加强记忆
哈希表遍历顺序来自内部布局，而内部布局会随容量、冲突处理、扩容、删除和随机种子变化。除非文档把顺序写进契约，否则不要让业务、测试或序列化依赖它。要顺序就选顺序结构，别从哈希表里“猜顺序”。