TreeMap是NavigableMap最常用且默认的实现，支持范围查询、反向遍历和导航方法；key需实现Comparable或传Comparator，非线程安全，视图操作与原map联动。
TreeMap就是最常用的NavigableMap实现
Java里NavigableMap是接口，不直接new；你日常用的TreeMap已经实现了它所有方法。别绕路去查抽象类或自定义实现——除非有特殊排序或线程安全需求，否则TreeMap就是你的默认选择。
常见错误：有人看到文档说“NavigableMap支持反向遍历”，就试图把HashMap强转过去，结果抛ClassCastException。记住：HashMap不实现NavigableMap，也不支持任何范围操作。
-
TreeMap构造时若没传Comparator，key必须实现Comparable，否则put时抛ClassCastException - 如果key是自定义类，忘了重写
compareTo()或没保证逻辑一致性（比如a.equals(b)为true但a.compareTo(b) != 0），subMap()等方法行为会错乱 -
TreeMap不是线程安全的；并发读写要用Collections.synchronizedSortedMap()包装，或改用ConcurrentSkipListMap
headMap/tailMap/subMap三个范围视图的区别和陷阱
这三个方法都返回NavigableMap子视图，不是新拷贝——原map改了，视图立刻可见；视图删元素，原map也跟着删。这是性能优势，也是坑的来源。
关键区别在边界控制：headMap(K toKey, boolean inclusive)和tailMap(K fromKey, boolean inclusive)的inclusive参数决定是否包含端点；而subMap(K fromKey, boolean fromInclusive, K toKey, boolean toInclusive)要同时指定两端是否闭合。
立即学习“Java免费学习笔记（深入）”；
- 不带
boolean参数的老版方法（如headMap(K)）默认exclusive，容易误以为包含toKey，结果漏掉一个元素 -
subMap(from, true, to, false)等价于数学区间[from, to)，符合多数业务场景（比如查“2024-01-01到2024-01-31的日志”，不含2月1日） - 如果
fromKey > toKey，或者任一key不在map中，subMap直接抛IllegalArgumentException，不是返回空map
ceilingKey/floorKey这类导航方法的实际用途
这些方法不是炫技用的——它们解决的是“找最近的合法键”问题，比如价格档位匹配、时间戳对齐、路由前缀查找。比自己写二分或遍历快，且语义清晰。
ceilingKey(K key)返回≥key的最小键；floorKey(K key)返回≤key的最大键；higherKey(K key)和lowerKey(K key)则严格大于/小于（不包含等于）。
- 当key不存在时，
get(key)返回null，但ceilingKey(key)可能返回下一个有效key——这正是它不可替代的地方 - 如果map为空，所有导航方法都返回null；别假设它们抛异常
- 注意null安全：key为null时，除非构造
TreeMap时用了允许null的Comparator，否则直接NPE
descendingMap()和反向遍历的性能真相
descendingMap()返回的是原map的反向视图，不是重建一棵逆序树，所以O(1)创建、O(log n)单次查询，和正向操作开销一致。但它返回的仍是NavigableMap，可以继续链式调用headMap或ceilingEntry。
常见误用：有人用treeMap.descendingMap().entrySet()再转ArrayList来“倒序遍历”，其实完全没必要——直接用descendingMap().forEach(...)或descendingMap().values().iterator()更轻量。
-
descendingMap()返回的map修改会影响原map，但它的comparator()返回的是原comparator的逆序版本，别拿它和原map的comparator做==判断 - 如果原map用的是自然顺序，
descendingMap()里firstKey()就是原map的lastKey()，别硬记，现场试一下System.out.println(map.descendingMap().firstKey())最可靠 - 多层嵌套视图（比如
subMap(...).descendingMap().tailMap(...)）逻辑容易绕晕，优先拆成两步：先取子视图，再反向，可读性高且不易出错
真正难的不是记住每个方法名，而是想清楚你要的到底是“包含端点的区间”还是“严格大于”，以及是否接受视图与原map联动。边界条件多敲两行测试，比背API管用。
