Stream分页本质是内存切片：先skip()跳过前N个已加载元素，再limit()取M个；要求数据必须全量驻留内存，不适用于数据库或流式数据源，否则导致全量查询和高GC压力。
Stream.limit() 和 skip() 的分页行为本质是什么
它们不是数据库分页，而是对已加载到内存的集合做切片——先 skip() 跳过前 N 个元素，再 limit() 取 M 个。这意味着整个原始集合必须已存在于内存中，否则无法跳过未加载的数据。
常见错误现象：Stream.generate(() -> fetchFromDB()).limit(10) 看似“取前 10 条”，但若 fetchFromDB() 是远程调用，它可能被反复执行（取决于中间操作是否短路），且根本无法实现“跳过前 20 条再取 10 条”的语义。
- 适用场景：本地 List/Array 等已完全加载的数据源，比如缓存中的用户列表、配置项集合
- 不适用场景：大数据量、流式数据源（如文件逐行读取、数据库游标）、响应式流（如 Flux）
- 性能影响：skip(n) 需遍历前 n 个元素（即使不消费），时间复杂度 O(n)，limit(m) 后续也仍需遍历 m 次；整体是 O(n + m)，非 O(1)
正确写法：先 collect 再 stream，避免重复计算
直接在未求值的 Stream 上链式调用 skip() 和 limit() 没问题，但前提是源头不带副作用。最稳妥的方式是确保数据已固化为 List 或数组。
错误示范：someService.findAll().stream().skip(20).limit(10).collect(...) —— 若 findAll() 每次都查库，就触发了 1 次全量查询，但仍是内存分页，不是 SQL 分页。
- 推荐做法：先
list = service.findAll()，再list.stream().skip(page * size).limit(size).toList() - Java 16+ 可用
.toList()，旧版本用.collect(Collectors.toList()) - 注意
skip()参数为 long，传负数会抛IllegalArgumentException；limit()同理
和数据库分页的关键区别在哪
这是最容易混淆的点：Stream 分页不会减少数据库压力，也不会降低网络传输量。它只是把“分页”这件事从 SQL 层移到了应用内存层。
典型错误认知：“用了 skip() 就等于 limit offset”——其实不然。PostgreSQL 的 OFFSET 20 LIMIT 10 是服务端跳过前 20 行再返回，而 Java 的 skip(20).limit(10) 是先把全部结果拉到 JVM 堆里，再丢弃前 20 个。
- 当数据量大（如 10 万条记录）时，
skip(99990).limit(10)仍需遍历 99990 个对象，GC 压力明显 - 若原始集合是
ArrayList，skip(n)实际是跳过索引，较快；但如果是LinkedList，每次 skip 都要链表遍历，性能更差 - 没有内置的“总条数”支持，需额外调用
list.size()，不能像 MyBatis-Plus 的 Page 对象那样自动携带 total
什么时候可以放心用，什么时候该立刻换方案
能用的前提非常具体：数据集小（≤ 数千）、变化不频繁、已常驻内存（如枚举列表、配置项、本地缓存），且业务接受“跳过即丢弃”的语义。
一旦出现以下任一情况，就应该停用 Stream 分页，改用真实分页机制：
- 原始数据来自数据库，且单表记录 > 1000 条 → 改用 JPA 的
Pageable或 MyBatis 的RowBounds/PageHelper - 需要响应“第 1000 页”，而每页 20 条 → 此时
skip(19980)已不可接受 - 数据源是
InputStream、File.lines()或其他惰性流 →skip()会强制消费并丢弃，无法 rewind
最常被忽略的一点：Stream 分页无法与排序安全组合。如果先 sorted() 再 skip()，那没问题；但如果排序逻辑依赖外部状态（比如按实时评分），而你又只对子集排序，结果就不可靠。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
