TreeSet能自动排序是因为其底层基于TreeMap和红黑树实现，所有元素作为TreeMap的key存储，由比较器决定排序与去重逻辑。
TreeSet 为什么能自动排序？底层靠的是 TreeMap + 红黑树
TreeSet 本身不存数据，它只是 TreeMap 的一层封装：所有元素作为 TreeMap 的 key 存储，value 固定为一个静态对象 PRESENT。真正负责排序和去重的，是底层的 TreeMap —— 而 TreeMap 基于红黑树实现。
红黑树是一种自平衡二叉搜索树，天然满足“左子树 add()，TreeSet 就委托 TreeMap.put() 执行插入，并根据比较结果（compareTo() 或 compare()）决定往左走还是往右走。这个过程本身就完成了排序，不是插入完再统一排序。
- 插入、查找、删除时间复杂度都是
O(log n)，比HashSet稍慢，但换来了有序性 - 红黑树通过颜色标记 + 旋转操作维持近似平衡，避免退化成链表
- 没有“排序触发时机”——排序发生在每个
add()内部，实时生效
自然排序失败？90% 是因为没实现 Comparable 或传 Comparator
对 Integer、String 这类 JDK 自带类型，TreeSet 能直接排序，是因为它们已实现 Comparable 接口；但自定义类（比如 Student）如果不做任何处理，运行时会直接抛出 ClassCastException：
java.lang.ClassCastException: class Student cannot be cast to class java.lang.Comparable
这不是语法错误，而是运行时类型检查失败 —— TreeSet 在第一次 add() 时尝试调用 compareTo()，发现对象没实现该接口。
立即学习“Java免费学习笔记（深入）”；
- 方案一：让类实现
Comparable，重写compareTo()（适合有唯一自然序的场景） - 方案二：构造 TreeSet 时传入
Comparator实例（更灵活，支持多套排序逻辑，优先级高于Comparable） - 注意：
Comparator中若涉及null值比较，必须显式处理，否则可能抛NullPointerException
字符串排序为何出现 "Banana" 在 "apple" 前面？Unicode 大小写敏感是默认行为
看这个常见现象：
使用 inotes CLI 从终端管理 Apple Notes。当需要在 macOS 的 Notes.app 中列出、读取、创建、编辑、删除或搜索备忘录时使用。
TreeSet<String> set = new TreeSet<>();
set.add("Banana"); set.add("apple"); set.add("Orange");
System.out.println(set); // 输出 [Banana, Orange, apple]
这是因为 String 的 compareTo() 按 Unicode 码点逐字符比较，而大写字母 A–Z（65–90）排在小写字母 a–z（97–122）前面。所以 "Banana" 的首字母 'B'（66）"apple" 的 'a'（97），自然排在前面。
- 想忽略大小写？用内置比较器：
new TreeSet<>(String.CASE_INSENSITIVE_ORDER) - 想按字典序但统一转小写？可写
(s1, s2) -> s1.toLowerCase().compareTo(s2.toLowerCase()) - 别依赖打印顺序反推逻辑 —— TreeSet 的迭代顺序就是其内部红黑树的中序遍历结果，严格由比较器定义
排序规则写错会导致去重失效或死循环，务必验证 compare() 返回值
TreeSet 判定“重复”的唯一依据是：比较器返回 0。如果 compare(o1, o2) == 0，就认为两者相等，后者不会被添加。
常见陷阱：
- 只比较部分字段（如只比
age），导致不同name的人被当成重复 -
compare()逻辑不满足“自反性、对称性、传递性”，可能引发TreeMap内部结构异常（极难调试） - 用减法计算数值差（如
this.age - o.age）可能整数溢出，推荐用Integer.compare(this.age, o.age)
最稳妥的写法是用 Objects.compare() 或 JDK 8+ 的 Comparator.comparing() 链式构造，既安全又可读。
红黑树的排序能力不是魔法，它完全依赖你提供的比较逻辑 —— 写错一行 compare()，整个集合的行为就不可信了。
