LinkedHashMap默认按插入顺序遍历，因其通过双向链表尾插实现O(1)时序维护，不依赖key比较或树平衡；accessOrder=true时转为访问顺序（LRU），遍历稳定性仅由链表保证，与哈希桶无关。
Java 中的 LinkedHashMap 是唯一在标准库中**默认按插入顺序遍历**且**无需排序开销**的 Map 实现——它不依赖 key 比较，也不重建结构，只靠链表维护时序。
为什么插入顺序比自然排序更轻量？
TreeMap 的“有序”是通过红黑树实现的，每次 put() 都要比较 key、旋转节点、维持平衡，时间复杂度是 O(log n)；而 LinkedHashMap 的插入顺序仅靠双向链表尾插，平均仍是 O(1)，扩容时链表顺序也完全不受影响。
- TreeMap 适合需要按 key 字典序/数值序稳定检索的场景（如范围查询
subMap()） -
LinkedHashMap适合“谁先来，谁在前”的语义，比如配置加载、日志上下文、缓存历史、API 响应字段顺序保真 - 如果 key 本身无自然序（如 UUID、JSON path 字符串），强行塞进 TreeMap 会徒增复杂度和错误风险
accessOrder=true 会破坏你想要的“插入顺序”
很多人误以为只要用了 LinkedHashMap，遍历就一定是写入顺序——关键看构造时第三个参数：accessOrder。
- 默认
new LinkedHashMap()等价于new LinkedHashMap(16, 0.75f, false)→ 插入顺序 -
new LinkedHashMap(16, 0.75f, true)→ 每次get()或对已有 key 调用put()，都会把该 entry 移到链表尾，头变成“最久未访问” - 这意味着：即使没新增数据，纯读取也会让遍历顺序动态漂移，不再是静态插入快照
遍历稳定性只依赖链表，和哈希桶无关
LinkedHashMap 的“有序”不是从哈希表里捞出来的，而是由每个 Entry 的 before 和 after 引用构成的独立双向链表保证的。
- 扩容（rehash）时，entry 在哈希桶中的位置可能变，但链表指针关系完全保留
-
keySet()、values()、entrySet()三者遍历顺序严格一致，因为它们都基于同一链表迭代 - 只要不调用
remove()、clear()或put()，遍历结果就是确定的、可复现的 - 没有反射或序列化能绕过链表“恢复原始顺序”——链表就是唯一事实来源
真正容易被忽略的是：插入顺序 ≠ 线程安全。并发修改 + 遍历仍会触发 ConcurrentModificationException；若需多线程下保持顺序，得套 Collections.synchronizedMap() 或改用 ConcurrentHashMap + 外部排序逻辑——但后者已失去 LinkedHashMap 的轻量本质。
