Java Stream API的skip()和limit()仅为内存切片工具，高效分页需满足数据已全量加载至内存的前提，适用于缓存数据、小规模本地计算或可控测试场景；数据库等外部源应避免全量加载，优先使用SQL分页或subList。
Java Stream API 本身不提供“高性能分页”的底层能力，它的 skip() 和 limit() 只是内存切片工具，真正能否高效，取决于你是否用对了场景、写对了顺序、避开了常见陷阱。
适用前提：数据必须已全部在内存中
Stream 分页只适合以下情况：
- 缓存中的用户列表、配置项、枚举值等静态或低频更新数据
- 本地计算生成的小规模中间结果（如过滤+映射后不超过几千条）
- 单元测试、后台管理类功能，且数据量明确可控（比如固定 500 条测试数据）
如果数据来自数据库查询、大文件读取或远程 API，直接 service.findAll().stream().skip().limit() 会导致全量加载再丢弃——看似简洁，实则浪费内存和时间。
正确写法：先固化，再分页
确保数据只查一次、只加载一次：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
✅ 推荐List<User> all = userService.findAll(); // 一次查库，结果可复用<br> List<User> page = all.stream()<br> .filter(u -> u.isActive())<br> .sorted(Comparator.comparing(User::getCreateTime))<br> .skip((long)(page - 1) * size)<br> .limit(size)<br> .toList();
❌ 危险
userService.findAll().stream()... —— 若 findAll() 每次都执行 SQL，就等于每页都查全表。
关键细节不能忽略
-
起始位置要算准：第
page页（从 1 开始）、每页size条，应跳过(page - 1) * size个元素；写成page * size会让第 1 页直接跳空 - skip 是 O(n)，不是 O(1)：跳过 99990 条，就得顺序遍历前 99990 个对象。页码越深，性能越差。10 万条数据取最后一页，仍需遍历近 10 万次
-
参数类型是 long：大页码时务必强转，避免整型溢出：
skip((long)(page - 1) * size) -
操作顺序影响结果和效率：先
filter再skip/limit；排序必须在skip前；limit后不要再filter或map，否则可能漏数据
更优替代方案（视场景选用）
- 数据来自数据库 → 直接用 SQL 的
LIMIT size OFFSET offset或游标分页（WHERE id > last_id ORDER BY id LIMIT size） - 数据已在内存且为
ArrayList→list.subList(from, Math.min(to, list.size()))更直观、下标安全、无遍历开销 - 需要拉取远程分页数据（如第三方 API）→ 自定义
Spliterator实现惰性加载流，避免手动维护页码状态
