Collectors.maxBy()返回Optional，需处理空集合；Comparator应避免嵌套null、慎用方法引用链；相同值时不保证稳定性；性能上忌重复计算或IO。
Collectors.maxBy() 返回 Optional，必须处理空集合情况
直接调用 Stream.collect(Collectors.maxBy()) 会返回 Optional<t></t>，不是原始对象。如果流为空（比如空列表），get() 会抛 NoSuchElementException，这是最常踩的坑。
正确做法是显式检查或提供默认值：
Optional<Person> maxPerson = people.stream()
.collect(Collectors.maxBy(Comparator.comparing(p -> p.getAge())));
Person result = maxPerson.orElse(null); // 或 orElseThrow(), orElseGet(() -> new Person(...))
- 永远别对
Optional.get()做无保护调用 - 如果业务上空集合有明确语义（如“查无数据”），用
orElse(null)比get()安全 -
orElseThrow()适合必须存在最大值的场景，否则应提前校验输入
Comparator 必须基于对象属性，不能直接传方法引用链
写 Comparator.comparing(Person::getAge) 没问题，但若属性是嵌套的（比如 person.getAddress().getCity()），方法引用无法直接展开，容易写出 NullPointerException。
稳妥写法是用 lambda 显式判空：
Comparator<Person> byCityName = (p1, p2) -> {
String c1 = p1.getAddress() != null ? p1.getAddress().getCity() : "";
String c2 = p2.getAddress() != null ? p2.getAddress().getCity() : "";
return c1.compareTo(c2);
};
- 避免
Person::getAddress::getCity—— 这语法不合法 - 如果嵌套属性可能为 null，lambda 中手动判空比依赖
Comparator.nullsFirst()更可控 - 数值型属性（如
int）用comparingInt()更高效，避免自动装箱
maxBy() 不保证稳定性，相同值时返回任意一个
当多个对象的比较字段相等（比如两个 Person 年龄都是 99），Collectors.maxBy() 只保证返回“其中一个”，不保证是第一个、最后一个或按原始顺序出现的那个。
需要稳定结果（如取最先出现的）得自己实现：
List<Person> candidates = people.stream()
.filter(p -> p.getAge() == maxAge) // 先算出 maxAge
.collect(Collectors.toList());
Person firstMax = candidates.isEmpty() ? null : candidates.get(0);
- 原生
maxBy()是并行友好的，但牺牲了顺序保证 - 如果流已排序或需确定性行为，先用
max()得到极值，再用filter().findFirst()更直观 - 不要依赖
maxBy()的返回顺序做业务逻辑
性能注意：避免在 comparator 中重复计算或 IO 操作
如果比较逻辑涉及耗时操作（比如调用 service.calculateScore(p)），每次比较都可能执行多次，导致性能陡增 —— 因为 comparator 可能被反复调用。
- 提前映射：用
map(p -> new AbstractMap.SimpleEntry(p, computeScore(p)))预计算再比较 - 或者改用
stream.max(Comparator)，它只遍历一次，比collect(maxBy())在某些场景下更轻量 - 字符串比较慎用
String::compareToIgnoreCase，小写转换有开销；如需忽略大小写且字段固定，可预存小写副本
maxBy()，而是 null 处理、相等情况的语义、以及 comparator 里藏着的隐式性能雷区。 
