TreeSet的Comparator必须是函数式接口实现，排序逻辑由其决定且初始化后不可变；多字段排序须用Integer.compare()等安全方法防溢出；推荐用Comparator.comparing().thenComparing()链式调用提升可读性与健壮性；自定义Comparator还直接影响contains()和remove()行为，判定相等仅依据compare(a,b)==0。
TreeSet构造时传入Comparator对象必须是函数式接口实现
Java中TreeSet底层依赖红黑树，排序逻辑完全由构造时传入的Comparator决定。不能靠重写compareTo()——那是Comparable的事；也不能在添加元素后动态改规则——TreeSet初始化后Comparator就固化了。
常见错误是试图用匿名内部类但漏掉compare()方法签名，或返回值不是int类型。JDK 8+推荐用Lambda，但必须确保参数类型明确（尤其泛型推导失败时）：
TreeSet<Person> set = new TreeSet<>((p1, p2) -> {
int nameCmp = p1.getName().compareTo(p2.getName());
if (nameCmp != 0) return nameCmp;
return Integer.compare(p1.getAge(), p2.getAge());
});多字段排序要避免Integer.compare()被替换成减法
用a - b计算整数差看似简洁，但在溢出场景下会翻转符号：比如Integer.MAX_VALUE - (-1)结果为负数，导致排序错乱。必须用Integer.compare(a, b)这类安全方法。
字符串、时间等非基本类型也同理：LocalDateTime要用compareTo()，别手写毫秒差；BigDecimal必须用compareTo()而非compareTo()以外的比较方式。
- 正确：
Integer.compare(p1.getScore(), p2.getScore()) - 危险：
p1.getScore() - p2.getScore() - 正确：
p1.getCreatedAt().compareTo(p2.getCreatedAt()) - 错误：
(int)(p1.getCreatedAt().toInstant().getEpochSecond() - p2.getCreatedAt().toInstant().getEpochSecond())
Comparator链式调用比手写嵌套更易维护
JDK 8引入Comparator.comparing()和thenComparing()，把多级排序拆成可读性高的链式表达。它自动处理null安全、类型推导和逆序逻辑，比手写if-else嵌套少出错。
比如按城市升序、年龄降序、姓名升序：
TreeSet<Person> set = new TreeSet<>(
Comparator.comparing(Person::getCity)
.thenComparing(Person::getAge, Comparator.reverseOrder())
.thenComparing(Person::getName)
);注意：thenComparing()第二个参数是另一个Comparator，不是布尔值；如果字段可能为null，得显式用comparing(..., Comparator.nullsLast(String::compareTo))。
自定义Comparator影响TreeSet的contains()和remove()行为
很多人只关注排序，却忽略TreeSet的查找逻辑也依赖同一个Comparator。如果Comparator把两个逻辑上相等的对象判为不等（比如只比姓名忽略年龄），contains()就会返回false，即使对象实际存在。
关键点：
-
TreeSet判定“相等”只看compare(a,b)==0，和equals()无关 - 如果业务上
Person的唯一性由id决定，那Comparator必须把id作为最终判据，否则remove(new Person(id=123))可能删不掉 - 调试时可打印
set.stream().filter(x -> comparator.compare(x, target) == 0).count()验证逻辑是否匹配预期
复杂排序规则里，最后那个thenComparing往往决定“是否视为同一元素”，这个细节容易被跳过。
