分页需计算起始偏移量：第page页（从1开始）、每页size条，应skip((page-1)*size)再limit(size)；顺序流安全，但无限流须先limit防卡死；limit与skip顺序不可颠倒，且不可在终止操作后调用。
Stream.limit() 和 skip() 的分页逻辑怎么算
分页不是简单套用 skip() 和 limit() 就能对上页码，关键在起始偏移量的计算。第 page 页（从 1 开始）、每页 size 条，应跳过前 (page - 1) * size 个元素，再取 size 个。
常见错误是把 page 当作从 0 开始——比如传入 page = 1 却写 skip(page * size)，结果第一页直接跳过全部；或者忽略空流、越界情况，导致返回空或抛 UnsupportedOperationException（尤其在并行流或某些中间操作后调用 limit()）。
- 必须确保流支持随机截断：
limit()和skip()在顺序流中总是安全的；但若上游是无限流（如Stream.iterate()）且未加limit()控制总量，分页可能卡死 - 不要在已终止的流上重复调用：每个流只能消费一次，分页逻辑必须在流构建的同一链路中完成
- 分页参数需校验：
page 或 <code>size 应提前拒绝，避免无意义计算
为什么不能先 skip() 再 limit() 就完事
看似 stream.skip((page - 1) * size).limit(size) 就够了，但实际有三个隐性成本：
-
skip(n)必须遍历并丢弃前n个元素，即使你只想要后面几个——当page很大（比如第 10000 页），它仍要逐个走过前 9999 × size 项，时间复杂度 O(n)，不是 O(1) - 如果流来自数据库查询或文件读取，这种“跳过式分页”无法下推到数据源，纯靠内存处理，极易 OOM
- 某些流实现（如
Arrays.stream().parallel()）下，skip()行为不保证顺序，可能导致结果错乱——JDK 文档明确说明skip()在并行流中“不保证跳过的是前 n 个”，除非流本身有序且稳定
替代方案：什么时候该换掉 skip + limit
真要分页，优先考虑源头支持（如 SQL 的 LIMIT offset, size 或 JPA 的 Pageable）。如果非得用 Stream 分页，可选更可控的方式：
- 用
Stream.toList()（JDK 16+）或Collectors.toList()先收集，再用List.subList()——适合数据量小、内存充足场景，代码清晰且下标安全 - 手写迭代器封装：用
Iterator手动推进(page - 1) * size步，再取size个，避免构造完整中间流 - 改用
Stream.takeWhile()+ 索引计数（JDK 9+）：配合AtomicInteger记录当前序号，在谓词里判断是否落在目标区间——比skip()略灵活，但依然无法规避遍历成本
示例（安全的手动索引控制）：
AtomicInteger index = new AtomicInteger(0);
stream.filter(x -> {
int i = index.getAndIncrement();
return i >= (page - 1) * size && i < page * size;
})
limit() 和 skip() 的链式调用顺序重要吗
重要，且只有一种合理顺序：先 skip()，再 limit()。反过来写 stream.limit(n).skip(m)（其中 m > 0）几乎总是错的——因为 limit(n) 先掐断了流长度，后续 skip(m) 可能直接跳过全部剩余元素，返回空流。
-
limit(10).skip(8)→ 最多返回 2 个（前提是原流 ≥10） -
skip(8).limit(10)→ 最多返回 10 个，从第 9 个开始（前提是原流 ≥18） - 如果写成
limit(5).skip(10)，结果必为空——limit(5)后流最多 5 个，skip(10)直接跳光
真正容易被忽略的是：一旦流中存在短路操作（如 findFirst()、anyMatch()），再在其后调用 skip() 或 limit() 会编译失败——因为终止操作已消费流，后续无法继续构建流水线。
