TreeMap 默认按 key 的自然顺序排序，依赖 Comparable 接口或构造时传入的 Comparator，内部通过红黑树在插入时动态维持有序与平衡，不支持批量插入后重排，范围视图是基于树结构的活引用切片。
TreeMap 默认按 key 的自然顺序排序，靠的是 Comparable 接口或 Comparator 实现
TreeMap 不是“自己决定怎么排”，而是把排序逻辑完全委托给 key 类型的比较能力。它内部不维护额外的索引或排序缓存，所有顺序都来自红黑树插入时对 key 的实时比较。
- 如果你用
Integer、String等 JDK 自带类型作 key，它们已实现Comparable，TreeMap 会自动调用其compareTo()方法 - 如果你用自定义类（比如
User）作 key，必须让它实现Comparable，否则运行时抛ClassCastException或NullPointerException（取决于 null 处理） - 也可以在构造时传入
Comparator，此时优先使用它，忽略 key 自身的compareTo()
注意：Comparator 和 Comparable **不能混用**。一旦构造时指定了 Comparator，TreeMap 就彻底无视 key 是否实现了 Comparable；反之，无参构造则强制要求 key 可比较。
红黑树不是“先建树再排序”，而是在插入每一节点时动态维持有序+平衡
很多人误以为 TreeMap 是“把所有元素塞进去后再统一排序”，其实完全
相反：每个 put() 都是一次红黑树标准插入操作——先按大小找到位置，再通过染色和旋转修复性质。中序遍历结果永远有序，不是因为“排好了”，而是因为红黑树本身就是二叉搜索树（BST）的平衡变种。
- 插入新节点默认为红色，避免直接破坏“黑高”（black-height）性质
- 真正耗时的操作是
balanceInsertion()：它检查父/叔/祖父节点颜色，分 case 处理（染色 or 左旋/右旋），最多执行 O(log n) 次操作 - 你无法绕过这个过程——哪怕只插一个元素，也走完整红黑树插入流程
所以，不要试图“批量插入后手动触发重排”；TreeMap 的有序性是插入即生效、不可绕过的底层契约。
subMap / headMap / tailMap 这些范围查询为什么快？因为红黑树支持 O(log n) 定位边界
像 subMap("apple", "pear") 这类操作，不是遍历全量数据过滤，而是利用红黑树的 BST 特性，先用两次二分查找分别定位起始和结束节点（类似 ceilingEntry() 和 floorEntry()），再以这两个节点为界构造子视图。整个过程不复制数据，只是持有了原树的引用和边界约束。
- 返回的
SortedMap是原 TreeMap 的“活视图”：后续对原 map 的增删可能影响子 map 的内容（例如删掉 subMap 范围内的 key） - 子 map 的
size()是懒计算的，首次调用才真正遍历路径计数，不是 O(1) - 如果边界 key 不存在，
subMap(from, to)仍能正确工作——它找的是“大于等于 from 且小于 to”的最小/最大键对应节点
别把它当成 SQL 的 WHERE 子句；它是基于树结构的指针切片，高效但有生命周期依赖。
自定义 Comparator 时最容易踩的坑：违反“一致性”和“可比性”契约
写错 Comparator 是 TreeMap 运行时出错最隐蔽的来源。JDK 不校验你的 compare 逻辑是否合理，但一旦违反约定，就会导致树结构错乱：重复 key、丢失 entry、甚至死循环（比如 compare(a,b) 返回正数，compare(b,a) 也返回正数）。
- 必须保证：对于任意非 null 的 a、b，
compare(a,b) == -compare(b,a) - 必须保证传递性：若
compare(a,b) > 0且compare(b,c) > 0，则compare(a,c) > 0 - 禁止在 compare 中做 I/O、锁、或依赖可变状态（如当前时间、随机数）
- 建议用
Comparator.nullsFirst()/nullsLast()显式处理 null，避免 NPE
一个典型反例：(a, b) -> Math.random() > 0.5 ? 1 : -1 —— 这会让红黑树彻底失衡，遍历时可能漏项或 StackOverflowError。
