treemap中compare返回0会被视为键等价，导致后put值覆盖前值；根本原因是红黑树仅依赖比较结果判定key是否相同，而非对象实际内容，故需确保不同key的比较结果永不为0。
TreeMap 里 key 被“吃掉”了，不是因为代码写错了，而是你返回了 0 —— 这个看似表示“相等”的数字，其实是 TreeMap 判定两个 key “完全一样”的信号。只要比较器对两个不同对象返回 0，TreeMap 就认为它们是同一个 key，后 put 的值会直接覆盖前一个。
为什么 compare 返回 0 就算“相同”？
TreeMap 底层是红黑树，插入时靠比较器决定节点位置。它不关心对象内容是否真的一样，只看 compare(o1, o2) 的返回值：
- 返回负数 → o1 排在 o2 左边
- 返回正数 → o1 排在 o2 右边
- 返回 0 → 认定 o1 和 o2 是等价键（equivalent keys），不再继续查找，直接用新 value 替换旧 value
哪怕两个对象 id 不同、内存地址不同、其他字段全不一样，只要 compare 方法返回 0，TreeMap 就当它们是同一个 key。
典型踩坑场景：按 value 排序却拿 key 当参数
想按 Map 的 value 降序排列，却写了这样的比较器：
new TreeMap<string object>((k1, k2) -> {
Object v1 = map.get(k1);
Object v2 = map.get(k2);
return ((Comparable) v2).compareTo(v1); // 假设 value 可比较
});</string>
问题在于：如果两个不同 key 对应的 value 恰好相等（比如都为 "default"），compare 就返回 0。TreeMap 看到 0，就认为 k1 和 k2 是同一个 key，第二次 put 时直接覆盖第一次的值——数据就这么丢了。
怎么避免？关键在“可区分性”
只要确保任意两个真实不同的 key，在比较逻辑中**永远不会返回 0**，就能保住所有数据。常用办法：
- 主排序字段相等时，追加次级字段（如 id、时间戳、原始索引）做兜底比较
- 用对象唯一标识参与比较，例如：
return Integer.compare(v1.hashCode(), v2.hashCode()) != 0 ? ... : k1.compareTo(k2) - 使用
Comparator.comparing(...).thenComparing(...)链式写法，天然支持多级回落
顺便检查：你的 Comparator 是否自反
再小的疏忽也会崩：如果 compare(x, x) 不等于 0，说明违反了自反性。TreeMap 可能不报错但行为异常，JDK 14+ 更会直接抛 IllegalArgumentException。最简验证法：
comparator.compare(x, x) == 0 成立。
不成立？立刻重写比较逻辑——别等上线后查半天丢数据的原因。
