Java Stream的skip()和limit()仅适用于内存中已加载的小规模数据分页，本质是内存切片而非数据库分页；正确写法为skip((page-1)size)，错误写法skip(pagesize)会导致第1页跳过全部数据。
Java Stream 的 skip() 和 limit() 确实能实现分页效果，但本质是内存切片，不是真正的数据库分页。它只适合数据已全部加载进内存的场景，比如本地 List、缓存列表或小规模配置集合。
分页写法要算对起始位置
第 page 页（页码从 1 开始）、每页 size 条，应跳过前 (page - 1) * size 个元素：
list.stream().skip((page - 1) * size).limit(size).collect(Collectors.toList())- 错误写法：
skip(page * size)—— 这会让第 1 页就跳过全部数据 - 参数类型是
long，传负数会抛IllegalArgumentException
只适用于已加载到内存的数据
这个组合不能减少数据库查询量或网络传输量：
- 如果
service.findAll()每次都查库，service.findAll().stream().skip(...).limit(...)仍会拉全量数据到 JVM，再丢弃前面部分 - 大数据量时（如 10 万条），
skip(99990)需遍历 99990 个对象，GC 压力明显 - 推荐先固化数据：
List<t> data = service.findAll(); data.stream().skip(...).limit(...).toList()</t>
性能和稳定性要注意这些细节
看似简单，实际有隐藏成本：
立即学习“Java免费学习笔记（深入）”；
-
skip(n)时间复杂度是 O(n)，不是 O(1)；ArrayList 跳索引快，LinkedList 每次跳都要遍历链表 - 并行流中
skip()不保证跳掉的是“前 n 个”，除非流本身有序且稳定 - 无限流（如
Stream.generate()）必须先limit()控制总量，否则分页可能卡死 - 流只能消费一次，分页逻辑必须在同一条流链路里完成，不能复用已终止的流
什么时候该换别的方案
真要分页，优先让数据源承担压力：
- 数据库查询直接用
LIMIT offset, size或 JPA 的Pageable - 数据量小且已驻留内存时，用
List.subList(from, to)更直观、下标安全 - 需要更精细控制（比如跳过带条件的前若干项），可用
AtomicInteger+filter()手动计数 - 别依赖 Stream 分页获取总条数——
size()得额外调用，它不自带total
