先 sorted 再 limit 是正确顺序：先全排序再取前 n 个，保证全局 top-n 准确性；limit 在前则仅对前 n 个元素排序，结果非全局 top-n；部分 jdk 对 sorted().limit(n) 有堆优化，但不可强依赖。
Java Stream 中 sorted() 和 limit() 的顺序直接影响性能和结果，不是随便调换的。
先 sorted 再 limit 是常规且安全的做法
这是最常用、语义最清晰的组合：先对全部元素排序，再取前 N 个。Stream 会完整执行排序（全排序），然后截断。
- 适用于数据量不大（比如几千以内）或必须保证“全局 Top-N”准确性的场景
- 代码直观，逻辑明确：
stream().sorted(comparator).limit(5) - 即使底层未做优化，行为可预测、可测试
limit 放在 sorted 前面毫无意义
stream().limit(10).sorted() 表示：先随机取前 10 个元素，再对这 10 个排序。结果不是整体数据的 Top-N，而是“前 10 条的排序”，容易引发业务误解。
- 常见于误以为能“提前剪枝”而写的错误链式调用
- 除非你明确只需要原始流头部子集的排序（比如日志前 10 条按时间排），否则这不是 Top-N 解法
sorted().limit(N) 在部分 JVM 实现中可能触发优化
虽然 Java 规范未强制要求，但主流 JDK（如 OpenJDK 17+）在某些条件下会对 sorted().limit(N) 做隐式优化——不执行完整排序，改用堆（如最小/最大堆）维护前 N 个元素，时间复杂度从 O(n log n) 降至 O(n log N)。
- 该优化依赖具体实现和数据规模，不可强依赖，但属于合理预期
- 若需确定性高性能，可手动用
PriorityQueue或第三方库（如 Eclipse Collections）替代 - 并行流下该优化通常失效，
parallelStream().sorted().limit(N)很可能回退为全排序 + 合并 + 截断，开销更大
真正想优化大数据 Top-N，得靠组合策略
单纯依赖 sorted + limit 不够，尤其面对百万级数据时：
- 先 filter：剔除明显不符合条件的元素（比如只保留评分 ≥ 4.0 的商品），大幅减少排序输入量
- 避免在 sorted 前 map 或 flatMap 出大量新对象，防止内存膨胀
- Comparator 尽量轻量：用
comparingInt替代comparing，避免装箱；预编译复用比较器实例 - 确认是否真需要排序：如果只要最大/最小值，用
max()/min()比sorted().limit(1)高效得多
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
