limit 是 stream 中实现早期终止的关键机制，作为有状态中间操作，它在输出 n 个元素后停止拉取和处理后续数据，配合 filter 可显著提升性能，但需避免置于 filter 前、慎用于无序流或并行流。
limit 在 Stream 中不是单纯“取前 N 个”，而是配合短路语义实现早期终止的关键机制——尤其在过滤后立即截断时，能显著减少不必要的元素处理和计算开销。
limit 的短路本质：让流提前结束
limit(n) 是一个**有状态的中间操作**，它会记录已输出元素个数。一旦达到 n，后续源数据就不再拉取或处理。这在以下场景中直接带来性能收益：
- 底层数据源是惰性生成的（如 Files.lines、Stream.iterate、数据库游标式分页流），limit 触发后，后续行/元素根本不会被读取；
- 前面有 filter 等耗时判断，limit 可阻止对大量不满足条件的元素执行后续逻辑；
- 与 findFirst、anyMatch 等终端操作不同，limit 不终止整个流 pipeline，但它让后续中间操作（如 map、sorted）只处理最多 n 个元素，降低内存与 CPU 压力。
典型高效用法：filter + limit 组合
这是最常用也最有效的优化模式。例如查询“前 5 个高热量菜品”：
.filter(d -> d.getCalories() > 300)
.limit(5)
.collect(toList());
只要找到第 5 个符合条件的菜，流就停止从 menu 拉取新元素。即使 menu 有 10 万条数据，实际可能只遍历几百项。
⚠️ 注意：若 filter 后结果稀疏（比如只有 2 个菜 >300 卡），limit(5) 会遍历完整个流才返回结果——此时 limit 不起加速作用，但也不会出错。
避免常见陷阱
- 不要放在 filter 前面：menu.stream().limit(1000).filter(...) 会先取前 1000 条再过滤，可能漏掉后面真正符合条件的元素；
- 慎用于无序流（如 Set.stream()）：limit 结果不可预测，无法保证“代表性”或“优先级”，不适合分页或 Top-N 语义；
- limit 后接 sorted 需警惕：sorted 是全量操作，会强制加载所有 limit 前的元素再排序——应改为 sorted().limit(n)，否则失去优化意义；
- 并行流中 limit 效果受限：并行环境下，各分段可能各自执行 filter+limit，最终合并时仍需协调，建议优先用 findAny/anyMatch 实现真正短路。
进阶技巧：与 short-circuiting 终端操作协同
limit 本身不触发执行，真正实现“短路查询”的是终端操作。搭配使用效果更佳：
- 要确认是否存在足够多匹配项：用 anyMatch 替代 collect + size 判断；
- 只需第一个结果：用 findFirst()，比 limit(1).collect(...) 更轻量；
- 构建分页查询（第 2 页，每页 10 条）：用 skip(10).limit(10)，但注意 skip 是线性跳过，大数据集慎用；
- 替代数据库 LIMIT/OFFSET 时，建议结合数据库原生分页（如 JPA Pageable），而非纯内存 limit/skip。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
