Java Stream的limit(10)仅在惰性数据源（如Files.lines、Stream.iterate）下真正短路省资源；对内存集合则不减少上游计算，filter+limit还可能扫描远超10条。
Stream.limit() 真的能“只处理前 10 条”吗？
不能一概而论。如果数据源本身是惰性求值的（比如 Stream.iterate()、Files.lines() 或数据库流式查询结果），limit(10) 会提前终止，后续元素根本不会生成或读取；但如果数据源是已加载到内存的 ArrayList 或数组，limit(10) 仍需先构造完整 Stream 管道，只是终端操作（如 forEach）只消费前 10 个——中间操作（如 filter、map）仍可能对全部元素执行，除非它们也支持短路。
哪些场景下 limit(10) 才真正省资源？
关键看上游是否支持“按需拉取”。常见有效组合：
-
Files.lines(Paths.get("huge.log")).filter(...).limit(10).collect(...)：逐行读取，匹配到 10 条就关闭流，不读剩余内容 -
Stream.iterate(0, i -> i + 1).filter(i -> i % 7 == 0).limit(10).toList()：无限流，生成+过滤到第 10 个满足条件的数即停 - JDBC 配合
ResultSet流式游标（如 PostgreSQL 的setFetchSize(Integer.MIN_VALUE)）+ 自定义 Spliterator，再套limit(10)：可避免全表拉取
反例：list.parallelStream().filter(...).limit(10) —— 并行流下 limit 无法短路分片，可能触发全部数据的 filter 计算。
filter + limit 组合时容易漏掉结果？
是的。如果 filter 过滤掉大量数据，limit(10) 会继续往后找，直到凑够 10 个满足条件的元素——这可能导致扫描远超 10 行。例如：
Files.lines(path)
.filter(line -> line.contains("ERROR"))
.limit(10)
.forEach(System.out::println);
若前 1000 行只有 2 行含 ERROR，这段代码会读到第 1000+ 行才停。解决思路：
- 用
takeWhile替代（Java 9+）：仅限“连续满足条件”的场景，如日志按时间倒序且只需最新 10 条 ERROR - 加计数器手动 break（不推荐函数式风格，但可控）
- 改用数据库 LIMIT + WHERE，把过滤和截断下推到源头
limit(10) 后接 collect(toList()) 会不会吃内存？
不会吃多——最终只存 10 个对象。但要注意中间对象生命周期：
- 如果
map中创建了大对象（如line -> new BigReport(line)），即使只留 10 个，那 10 个BigReport实例仍会常驻内存 - 若
limit前有distinct()或sorted()，这些操作必须看到全部输入才能输出首个元素，limit完全失效 - 调试时别用
peek(System.out::println)在 limit 前——它会强制触发所有中间步骤的日志输出，掩盖真实性能
真正省资源的关键从来不是 limit 本身，而是它能否让上游停止生产。盯着数据源头比盯着 Stream 管道更重要。
