HashMap遍历顺序不保证插入顺序，因其基于哈希值定位桶位置，与插入先后无关；应使用LinkedHashMap保持插入顺序。
因为 HashMap 的底层是哈希表，元素位置由键的哈希值决定，跟插入先后完全无关。
哈希值决定存储位置，不是插入顺序
HashMap 内部用一个数组（桶数组）存放元素，每个键调用 hashCode() 得到哈希值，再通过扰动函数和取模运算算出它该落在哪个桶里。比如 'A' 和 'a' 的哈希值差得远，可能被分到数组开头和末尾两个不同位置；而后面插入的 'r' 可能恰好跟前面某个键哈希冲突，放进同一个桶的链表或红黑树里——这些都跟“谁先插”没关系。
- 同一段代码多次运行，顺序往往看起来一样，这只是巧合，源于哈希算法和初始容量固定
- 一旦触发扩容（比如从16扩到32），所有元素要重新计算位置，顺序大概率就变了
- 哪怕只改一个字符、换一个 JDK 小版本，哈希值或扰动逻辑微调，输出顺序也可能不同
遍历时只是按桶数组从头扫到尾
调用 keySet() 或遍历 entrySet() 时，HashMap 实际上是依次检查内部桶数组的每个槽位：空的跳过，有元素的就拿出来。这个“从 0 到 length-1”的扫描顺序，是数组下标顺序，不是插入顺序，更不是字母顺序或大小顺序。
- 小数据量（比如不到 12 个）且没扩容时，你可能看到类似插入顺序的结果，但这是实现细节，不能当规律用
- 只要桶里发生哈希冲突形成链表或转成红黑树，那个局部顺序就由插入时间、树平衡规则等共同决定，不可预测
Character 键没有特殊待遇
有人以为用 char 或 Character 当键会“自然有序”，其实不会。'A'（ASCII 65）、'a'（97）、'f'（102）这些看似连续，但经过 HashMap 的哈希计算（h ^ (h >>> 16) 等扰动）后，映射到桶索引的过程已经打乱了原始数值关系。所以即使键是单个字母，也不代表它们会按字母表或插入顺序排列。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
- 别依赖 System.out.println(map.keySet()) 看起来“碰巧有序”来写逻辑
- 单元测试里如果用 HashMap 存校验结果并断言顺序，很可能在 CI 环境或换个 JVM 参数就失败
需要顺序怎么办？选对替代方案
真要保持插入顺序，直接换集合类型就行，不用自己排序或加序号：
- LinkedHashMap：开销极小，内部用双向链表记住插入顺序，迭代时按插入顺序返回，推荐首选
- TreeMap：按键自然顺序（或自定义 Comparator）排序，适合需要始终有序且支持范围查询的场景
- 如果只是临时按插入顺序处理一次，也可以把 keySet() 转成 ArrayList，再按原始插入顺序重建 Map（但不如直接用 LinkedHashMap 干净）
基本上就这些。HashMap 的无序不是 bug，是设计使然——它用放弃顺序换来了 O(1) 平均查找性能。理解这点，就不会在该用 LinkedHashMap 的地方硬扛 HashMap 了。
