stream api排序需先filter再sorted以减少数据量，慎用parallelstream并确保comparator无副作用，多字段排序用thencomparing链式构建，空值处理须显式指定nullsfirst/nullslast。
处理大型数据集时，Stream API 的排序不能只靠 sorted() 硬扛。关键在于减少参与排序的数据量、降低比较开销、合理利用硬件资源，并保障空值与并发安全。
优先过滤再排序
排序是有状态的中断操作，越晚执行越好。把 filter 放在 sorted 前面，能显著减少待排序元素数量：
- 错误写法：先
map或sorted，再filter—— 白跑大量无用计算 - 推荐顺序：
filter → map → sorted → collect - 例如：从百万订单中只取“已支付且金额 > 100”的记录再按时间排序，先
filter可将数据量压到几千级，排序效率提升数倍
慎用并行流，但用就要用对
parallelStream() 不是银弹，它适合“数据量大 + 单次比较耗时”的场景：
- 适用：对象字段需复杂解析（如 JSON 字符串提取后再比）、自定义比较逻辑含 I/O 或计算
- 不适用：纯
Integer或String的简单比较，此时并行开销可能超过收益 - 必须确保：Comparator 无副作用、不依赖共享可变状态；避免在其中修改外部变量或调用非线程安全方法
多字段排序用 thenComparing 链式构建
避免嵌套 Comparator 或手写 compare() 方法，链式调用更清晰、更高效：
- 主字段用
comparing(…)，次字段用thenComparing(…)，支持无限追加 - 每个字段可独立配置空值策略和方向，例如：
comparing(Product::getCategory, nullsLast(naturalOrder()))<br> .thenComparing(Product::getPrice, nullsFirst(reverseOrder()))<br> .thenComparingLong(p -> p.getId())
- 注意：
thenComparingInt/thenComparingLong比thenComparing+ lambda 更快，避免装箱
空值与类型安全不可跳过
真实业务数据总有 null，忽略它会导致 NullPointerException 或排序错乱：
- 统一用
nullsFirst()或nullsLast()包裹字段比较器，不要依赖默认行为 - 对数值字段，优先用
comparingInt/comparingLong替代comparing，既防null又免装箱 - 字符串排序慎用
String::compareTo，建议用String.CASE_INSENSITIVE_ORDER或自定义Collator处理本地化需求
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
