navigablemap 不是 treemap 的“高级马甲”，其核心价值在于提供 ceilingkey()、floorentry() 等方向性导航方法，而非仅排序；必须用 treemap 或 concurrentskiplistmap 实例化，且需实际调用导航操作才体现优势。
为什么 NavigableMap 不是 TreeMap 的“高级马甲”
它确实是 TreeMap 的主要实现接口，但关键区别在于：接口定义了**方向性检索能力**，而不仅仅是“已排序”。如果你只用 get() 或 keySet()，那和普通 Map 没差——真正价值在 ceilingKey()、floorEntry() 这类带语义的导航方法上。
常见错误是把 NavigableMap 当成“更酷的 Map”去泛型声明，却没调用任何导航方法。结果代码写得比 HashMap 还慢（因为红黑树开销白扛了）。
- 必须用
TreeMap或ConcurrentSkipListMap实例化，接口本身不能 new -
NavigableMap是接口，TreeMap是它的标准实现；别写new NavigableMap()—— 编译不过 - 如果不需要反向遍历或边界查找，用
SortedMap就够了，少一层抽象
ceilingKey() 和 floorKey() 到底查的是“谁”
这两个方法名字容易让人脑补成“向上取整/向下取整”，但实际逻辑更接近“找最近的合法邻居”：前者返回 ≥ 给定 key 的最小键，后者返回 ≤ 给定 key 的最大键。没有匹配时返回 null（非 Optional！）。
典型场景：价格区间映射、时间戳对齐、分段配置查找。比如按毫秒时间戳查最近生效的配置项，用 floorEntry(timestamp) 比遍历 entrySet() 快得多。
立即学习“Java免费学习笔记（深入）”；
- 输入 key 不存在时，
ceilingKey(5)在 {1=, 3=, 7=} 中返回7，不是null - key 比所有键都大，
ceilingKey()返回null；比所有键都小，floorKey()返回null - 注意 null 安全：调用前最好判空，尤其在流式链式调用里（如
map.ceilingKey(k).toString()会 NPE）
反向遍历用 descendingMap() 还是 descendingKeySet()
两者都返回逆序视图，但本质不同：descendingMap() 返回的是整个 NavigableMap 的反向代理，支持所有导航操作；descendingKeySet() 只是 Set 视图，不支持 higherKey() 等方法。
性能上没差异——都是 O(1) 返回视图，不复制数据。但误用会导致编译错误或逻辑错乱。比如想查“小于某值的最大键”，在反向 map 上该用 higherKey()（因为方向翻转了），而不是继续用 floorKey()。
- 需要继续做导航操作（如
lowerEntry()、headMap()），必须用descendingMap() - 只读键集合且要逆序迭代，
descendingKeySet()更轻量 -
descendingMap()返回的 map 仍是线程不安全的，多线程下需额外同步
subMap() 的 fromInclusive / toInclusive 参数陷阱
这个四参数版本（subMap(fromKey, fromInclusive, toKey, toInclusive)）最容易踩坑：两个布尔值控制的是**端点是否包含在结果中**，但底层仍依赖 key 的自然顺序或比较器。如果传入的 fromKey > toKey，直接抛 IllegalArgumentException——哪怕你设了 fromInclusive=false 也救不了。
典型错误是拿字符串做范围切片时忽略字典序，比如 subMap("a", true, "Z", true) 在 ASCII 下会为空（因为 "Z"
- 务必确保
fromKey≤toKey（按 map 的 Comparator 判断） - 如果不确定大小关系，先用
compare()验证，别靠猜 - 边界 key 不存在时，inclusive 参数仍生效：例如
subMap(2,true,4,false)在 {1=,3=,5=} 中返回 {3=}
最麻烦的其实是自定义 Comparator 和 null 键混用——一旦 comparator 不支持 null，所有导航方法都会炸，而且错误信息里根本看不出是 comparator 的锅。
