comparator.compare() 遇 null 崩溃主因是实现中未判空就调用方法；应分清 null 所在位置，优先用 comparator.nullsfirst/last 包装非 null 比较器，字段提取可能为 null 时必须包装其比较器，手写 compare 需显式分支处理所有 null 情况。
Comparator.compare() 遇到 null 就崩？先确认 null 是谁的
NullPointerException 不是 Comparator 本身抛的，而是你实现的 compare() 方法里对 null 做了非空操作（比如调用 .compareTo() 或 .equals()）。关键要分清：是第一个参数为 null？第二个？还是两者都可能？不同情况处理逻辑不同。
常见错误现象：a.compareTo(b) 中 a 为 null，直接抛 NPE；或用 Objects.compare(a, b, String::compareTo) 却没意识到第一个参数 a 本身不能为 null。
- 如果业务允许
null出现在待排序集合中，必须在compare()内显式判断，不能依赖下游方法兜底 -
Comparator.nullsFirst()和Comparator.nullsLast()只包装「非 null 值的比较器」，它们不帮你做空值安全的委托比较 - 不要写
(a, b) -> a.compareTo(b)这种裸调用——除非你 100% 确保a和b永远非 null
用 Comparator.nullsFirst() / nullsLast() 包装已有比较器
这是最简洁、可读性最好的方式，适用于你已有「只处理非 null」的比较逻辑（比如字段本身是 String，你想按字典序排）。
它内部会先检查两个参数是否为 null，再决定谁排前面，最后才把非 null 值交给你的原始比较器。注意：包装后的比较器仍要求「原始比较器能安全处理非 null 输入」。
Comparator<user> byName = Comparator.comparing(
u -> u.getName(),
Comparator.nullsFirst(String::compareTo)
);</user>
-
Comparator.nullsFirst(…)把null排最前；nullsLast(…)排最后 - 传入的比较器（如
String::compareTo）不能接收null——所以u.getName()返回null时，由外层nullsFirst拦截，不会进到String::compareTo - 不支持自定义 null 之间的大小关系（比如想让
null视为 -1 而不是统一排最前），这时得手写逻辑
手写 compare() 时显式判空并约定语义
当需要精细控制 null 的排序含义（例如：把 null 当作最小值、最大值，或按某字段默认值替代），就得重写 compare() 并自己处理所有分支。
核心原则：先判空，再分支，避免任何对 null 的方法调用。别依赖「短路」侥幸——a == null || a.compareTo(b) 在 <code>a 为 null 时虽不会执行 compareTo，但若 b 为 null，逻辑就错了。
Comparator<user> byAge = (u1, u2) -> {
Integer a = u1 != null ? u1.getAge() : null;
Integer b = u2 != null ? u2.getAge() : null;
return Comparator.nullsLast(Integer::compareTo).compare(a, b);
};</user>
- 推荐复用
Comparator.nullsFirst/Last处理包装后的字段值，而不是从头写 if-else - 如果字段类型是基本类型包装类（如
Integer），注意int默认值 0 和null含义不同，别混淆 - 避免在
compare()里做耗时操作（如数据库查询、IO），它会被频繁调用
Stream.sorted() 或 Arrays.sort() 中漏掉 null 处理的典型坑
很多人以为用了 Stream.sorted(comparator) 就万事大吉，结果集合里有 null 还是 NPE——问题往往出在 comparator 构建环节，而非调用位置。
一个易忽略点：Comparator.comparing(Function, Comparator) 的第二个参数是「用于比较提取值的比较器」，不是「用于比较原对象的」。如果你写成 comparing(User::getName, nullsFirst(String::compareTo)) 是对的；但若误写成 comparing(User::getName, nullsFirst(Comparator.naturalOrder()))，后者等价于 nullsFirst((a,b) -> a.compareTo(b))，而 a 此时是 String，没问题；但如果提取函数返回 null，这个外层 nullsFirst 才生效。
- 检查提取函数（如
User::getName）是否可能返回null；如果会，就必须用nullsFirst/Last包装其返回值的比较器 -
Arrays.sort(T[], Comparator)同样适用这套规则，没有特殊豁免 - 测试时一定要构造含
null字段、含null元素、以及两者混合的用例
真正容易被忽略的是：null 可能出现在链式调用的任意一环——比如 user.getAddress().getCity()，中间任一环节为 null 都会导致 NPE，而 Comparator.nullsFirst 只管最终提取值，不管提取过程。这种场景必须提前防御性取值，或者改用 Optional 链式处理后再映射。
