TreeSet判定元素重复只依据compareTo()或compare()返回值是否为0，因底层红黑树依赖比较结果定位节点：返回0即逻辑位置重合，视为已存在；若compareTo()与equals()不一致会导致contains()失败等逻辑错误。
TreeSet 判定两个元素是否重复，**不看 equals()，只看 compareTo() 或 compare() 的返回值是否为 0**。只要 a.compareTo(b) == 0，TreeSet 就认为 a 和 b 是同一个元素，后添加的那个会被直接丢弃。
为什么只靠返回 0 就算“相等”？
TreeSet 底层是红黑树（基于 TreeMap），插入时必须确定新元素在树中的位置。它通过反复调用比较方法来决定往左子树还是右子树走：
- 返回负数 → 当前元素小，往左走
- 返回正数 → 当前元素大，往右走
- 返回 0 → 两者“逻辑上位置重合”，无需再往下找，直接视为已存在
这不是 bug，而是设计契约：Comparator 或 Comparable 定义的不仅是“大小关系”，也隐含了“相等性语义”。
常见误解：equals() 和 compareTo() 不一致会怎样？
比如 Person 类只按 name 比较，但重写了 equals() 要求 name + age 都相同才相等：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- new Person("Alice", 20) 和 new Person("Alice", 25) 的 compareTo() 返回 0 → TreeSet 只留一个
- 但 person1.equals(person2) 返回 false → contains() 查不到、remove() 删不掉
- 结果：集合 size 是 1，但业务上这两个对象明明不同，逻辑错乱
怎么写安全的 compareTo()？
核心原则：**让“比较相等”和“业务相等”尽量对齐；如果无法完全对齐，至少保证“真正不同的对象绝不返回 0”**。
- 优先使用多个字段组合判断，例如先比 id，id 相同再比 createTime
- 避免仅依赖可能重复的字段（如姓名、邮箱前缀、字符串长度）
- 若用 Comparator，开头加类型检查：if (a.getClass() != b.getClass()) return -1;
- 空值必须显式处理，否则抛 NullPointerException
对比 HashSet，理解更清晰
HashSet 去重靠 hashCode() + equals()，两个对象即使内容一样，只要不是同一类或没重写 equals，就可能共存；TreeSet 完全相反——它不管你是谁、长什么样，只信比较结果。返回 0 就是“树里已经有个一模一样的位置”，没有商量余地。
