TreeSet去重只依赖compareTo()或compare()返回0，与equals()无关；底层红黑树据此判断逻辑相等并拒绝重复插入；Comparable/Comparator必须满足一致性要求，否则引发contains等行为异常。
TreeSet 中元素的唯一性与去重规则，**不依赖 equals() 和 hashCode()，而是完全由 Comparable 接口（或 Comparator）定义的“相等性”决定**：两个元素 compareTo() 返回 0，TreeSet 就认为它们重复，只保留一个。
compareTo() 返回 0 是去重的唯一依据
TreeSet 底层是红黑树，插入时通过 compare 方法（来自 Comparable.compareTo() 或 Comparator.compare()）进行比较和定位。当 a.compareTo(b) == 0 时，TreeSet 认为 a 和 b “逻辑上相等”，后者会被拒绝插入。
注意：这和 HashSet 完全不同——TreeSet 不调用 equals()，哪怕两个对象实际不等（equals 返回 false），只要 compareTo 返回 0，就会被当作重复。
- 若 Student 实现 Comparable，按 name 比较：new Student("Alice", 20) 和 new Student("Alice", 25) 的 compareTo 返回 0 → TreeSet 视为同一元素，后者插不进去
- 即使你重写了 equals() 判断 age 也必须相同，TreeSet 仍无视它，只看 compareTo 结果
Comparable 的实现必须满足“一致性”要求
为了 TreeSet 正确工作，compareTo 必须满足自反性、对称性、传递性，并且compareTo(a, b) == 0 必须与 a.equals(b) 保持一致（强烈推荐，否则行为易混淆）。
立即学习“Java免费学习笔记（深入）”；
- 不一致的典型陷阱：按 id 比较（compareTo 只看 id），但 equals 同时比较 id + name → 两个 id 相同但 name 不同的对象，TreeSet 认为重复，但 equals 返回 false
- 后果：集合 size 看似正常，但 contains() 可能返回 false（因为 contains 用的是 equals），造成逻辑矛盾
手动传入 Comparator 时规则完全相同
即使不实现 Comparable，用 TreeSet(Comparator) 构造，去重逻辑依然只看 compare(a, b) == 0。此时 Comparator 承担了 Comparable 的角色。
- Comparator
c = (x, y) -> Integer.compare(x % 10, y % 10);
TreeSetset = new TreeSet(c);
set.addAll(Arrays.asList(3, 13, 23)); // 最终只保留一个（比如 3），因为 3%10 == 13%10 == 23%10 - 这种“模10去重”是合法的，但需明确业务是否接受这种语义
想保留“值不同但比较相等”的对象？不能用 TreeSet
如果业务上两个对象确实不同（如数据库主键不同），但 compareTo 因业务逻辑返回 0，TreeSet 无法容纳二者。这时应：
- 改写 compareTo，加入次要字段（如 id）打破完全相等，确保真正不同的对象返回非零结果
- 改用 List + 手动去重，或 LinkedHashSet + 自定义 equals/hashCode
- 用 TreeMap 存储，key 为复合标识（如 id），value 为对象，绕过排序容器的去重限制
