TreeSet基于TreeMap实现，按自然顺序或Comparator排序，要求元素可比较且非null，重复元素被丢弃；排序逻辑仅依赖compareTo或compare方法，不响应toString等其他方法。
TreeSet 默认按自然顺序排序，本质是用 TreeMap 做底层存储
TreeSet 本身不存储元素，它只是 TreeMap 的一个包装：把传入的每个元素当作 TreeMap 的 key，value 固定为 PRESENT（一个静态的 Object 实例）。所以排序逻辑完全由 TreeMap 决定——而 TreeMap 是基于红黑树实现的，插入时会根据 key 的比较结果调整节点位置。
这意味着：只要元素实现了 Comparable 接口（比如 Integer、String），或者你显式传入了 Comparator，TreeSet 就能自动维持有序。
- 没实现
Comparable且没传Comparator→ 添加元素时抛ClassCastException -
TreeSet不允许null（除非用自定义Comparator显式处理null） - 重复元素会被静默丢弃——因为底层是 map，key 重复即覆盖
自定义排序必须传 Comparator，不能靠重写 toString 或 getter
很多人误以为重写对象的 toString() 或加个 getSortKey() 方法就能影响 TreeSet 排序，其实完全无效。TreeSet 只在插入/查找时调用 compareTo()（自然排序）或 compare(a, b)（比较器），其他方法一概不触发。
正确做法是：要么让类实现 Comparable，要么构造 TreeSet 时传 Comparator。后者更灵活，尤其适合同一类需多种排序逻辑的场景。
立即学习“Java免费学习笔记（深入）”；
TreeSetbyAge = new TreeSet<>((a, b) -> Integer.compare(a.getAge(), b.getAge())); TreeSet byName = new TreeSet<>((a, b) -> a.getName().compareTo(b.getName()));
- 使用 lambda 时注意避免空指针：如果
getName()可能返回null，得先判空，否则抛NullPointerException - 不要在
Comparator里做耗时操作（如查数据库、IO），会影响 add/remove 性能 - 比较逻辑必须满足「自反性、对称性、传递性」，否则 TreeSet 行为不可预测（比如
contains()返回 false 却能遍历到）
TreeSet 的时间复杂度和实际性能陷阱
理论复杂度是 O(log n) 插入/查找/删除，但常被忽略的是：每次比较都可能触发对象方法调用或字符串计算。比如用 String::compareTo 排序长文本，实际耗时跟字符串长度强相关，不是单纯 log n 次 CPU 指令。
- 小数据量（ArrayList + Collections.sort() 可能比 TreeSet 更快——红黑树的常数开销大
- 频繁增删 + 少量遍历 → TreeSet 合适；只插入一次、后续只读遍历 → 排好序的
ArrayList更省内存 - 如果排序字段经常变化（如对象属性被修改），TreeSet 不会自动重排——你得先
remove再add，否则位置错乱
别把 TreeSet 当作“自动更新”的有序视图
TreeSet 是快照式有序结构，不是响应式视图。它不监听元素内部状态变化。比如：
TreeSetset = new TreeSet<>((a, b) -> Integer.compare(a.x, b.x)); MutablePoint p = new MutablePoint(10); set.add(p); p.x = 5; // ✅ 对象字段变了，但 TreeSet 中节点位置不会动
此时 p 在树中的逻辑位置仍按 x == 10 计算，导致后续 floor(7) 或 higher(6) 等范围查询出错。
- 可变对象放进 TreeSet 是高危操作，应尽量用不可变类（
String、LocalDateTime、自定义 final 类） - 真要改排序依据，必须先
set.remove(p)，再set.add(p)，否则树结构损坏 - 没有“刷新”或“re-sort”方法——排序只发生在插入时刻
