Stream分页仅适用于内存中已加载的静态小数据集，如缓存列表、枚举等；不适用于数据库直查、大文件或远程API场景，且skip()时间复杂度为O(n)，深页性能差，应优先用数据库物理分页。

Java Stream 的 skip() 和 limit() 可以实现分页，但“高效”需谨慎定义——它本质是内存内切片，不是数据库级的物理分页。真正高效的前提是：数据已全部加载到内存、体量可控、无需反复查库。否则，用错场景反而拖慢系统。

明确适用边界：什么情况下能用

Stream 分页只适合逻辑分页（即内存分页），核心要求是原始集合已完整驻留 JVM 堆中：

• 缓存中的用户列表、配置项、枚举集合等静态或低频更新数据
• 本地计算生成的小规模中间结果（如过滤+映射后的 List，不超过几千条）
• 单元测试或后台管理类功能中，数据量明确可控的场景

不适用于：数据库查询结果直连 Stream、大文件逐行流式读取、远程 API 分页拉取、百万级 List —— 这些都会导致全量加载、高内存占用和 GC 压力飙升。

正确写法：先固化再分页

避免在源头带副作用的操作上链式调用 skip/limit。最稳妥的方式是把数据先收集成 List 或数组：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

立即学习“Java免费学习笔记（深入）”；

• ✅ 推荐：List<User> all = userService.findAll(); // 一次查库，结果已缓存
     List<User> page = all.stream().skip((page - 1L) * size).limit(size).toList();
• ❌ 危险：userService.findAll().stream().skip(...).limit(...) —— 若 findAll() 每次都执行 SQL，就白做了全量查询，且无法复用
• ⚠️ 注意：skip() 和 limit() 参数类型为 long，传负数会抛 IllegalArgumentException

性能关键点：skip 不是 O(1)，而是 O(n)

很多人误以为 skip(99990) 很快，其实它必须顺序遍历前 99990 个元素（即使不消费），时间复杂度是线性的：

• 跳过第 1 页（size=20）：遍历 0~19 → 快
• 跳过第 5000 页（size=20）：遍历 0~99999 → 明显变慢
• 若总数据 10 万条，取最后一页，仍需遍历 99980 次

因此，页码越深，性能越差。如需支持深度翻页，应改用数据库 OFFSET/LIMIT 或游标分页，而非 Stream。

配合其他操作的实用组合

分页常与排序、过滤共存，注意操作顺序影响结果和效率：

• ✅ 先 filter 再 skip/limit：减少后续遍历量
    .filter(u -> u.isActive()).sorted(...).skip(...).limit(...)
• ✅ 排序必须放在 skip 前：否则分页后排序无意义
• ❌ 避免在 limit 后再 map/filter：可能丢掉本该保留的数据
• ? 总数统计独立进行：map.put("count", list.size())，不要用 collect.counting()，避免二次遍历