comparator链式调用失效主因是null未处理或thencomparing短路逻辑：comparing()遇null抛npe，需用nullsfirst/last显式声明；thencomparing仅当前项相等时触发，非全量执行。
Comparator.comparing() 链式调用为什么有时不生效
链式比较器失效，往往是因为中间某次 comparing() 返回了 null，而默认不处理 null 值——JDK 本身会直接抛 NullPointerException，而不是跳过或排到末尾。
常见于字段未初始化、数据库查出来为 null 的字段、或 Map.get() 返回 null 的场景。比如 comparing(Person::getAge).thenComparing(Person::getName)，只要 getAge() 返回 null，整个比较就崩了。
- 用
comparing(Function, Comparator.nullsFirst()/nullsLast())显式声明 null 策略，例如：comparing(Person::getAge, nullsLast(Comparator.naturalOrder())) - 避免在 lambda 中做可能抛异常的操作（如
obj.getName().toLowerCase()），先判空再取值 - 如果字段类型是基本类型包装类（
Integer、LocalDateTime），注意其 null 安全性比String更隐蔽
thenComparing() 后续条件不触发的典型原因
后续条件只在前一个比较结果为 0（即相等）时才执行。很多人误以为“所有条件都会参与计算”，其实它是短路逻辑——就像 && 运算符。
例如按部门排序再按薪资排序，但所有人的部门都一样，那 thenComparing 根本不会被调用；反过来，如果部门各不相同，第二个条件永远没机会运行。
- 调试时可在 lambda 里加日志（如
thenComparing(p -> { System.out.println(p); return p.getSalary(); })），确认是否进入 - 不要依赖
thenComparing做副作用操作（如修改状态、发请求），它可能完全不执行 - 多级排序逻辑复杂时，优先考虑提取成独立方法，比嵌套 lambda 更易读、易测
自定义 Comparator 和 Stream.sorted() 的性能陷阱
Stream.sorted() 是稳定排序，内部用的是双轴快排（JDK 14+）或归并排序（旧版），时间复杂度 O(n log n)，但每次比较都调用你的 compare() 方法——如果这个方法里做了 IO、正则匹配、或重复解析 JSON 字符串，性能会断崖式下跌。
典型反模式：thenComparing(p -> new SimpleDateFormat("yyyy-MM-dd").parse(p.getDateStr()))，每比一次都新建对象、解析字符串。
- 提前把耗时计算做好，存在字段或 Map 缓存里，排序时只读不算
- 避免在比较器中调用
toString()、substring()、split()等创建新对象的方法 - 对大数据量（>10k）排序，优先用
List.sort()而非Stream.sorted()，减少流开销和装箱成本
Java 8 之后推荐的链式写法 vs 兼容老版本的 fallback
JDK 8 引入了 Comparator.nullsFirst()、thenComparingInt() 等便捷方法，但有些项目还跑在 JDK 7 或 Android API 23 以下环境，这些方法不可用。
不是所有“链式”都靠 thenComparing 实现——手动实现 compare() 有时更清晰、更可控，尤其当逻辑含 if-else 分支或需要复用已有工具方法时。
- 纯 JDK 8+ 项目：优先用
comparing(...).thenComparingLong(...).thenComparing(..., nullsLast(...)) - 需兼容老版本：写个静态工具方法，内部用传统 if-else 比较，返回 -1/0/1，再传给
Comparator.comparing()的第三个参数（Comparator） - Android 开发注意：
Comparator.nullsFirst()在 API 24+ 才支持，低版本必须手写 null 判定逻辑
LocalDateTime.parse()。 
