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 终端节点、同步与异步等。
- ✅ 推荐：List
all = userService.findAll(); // 一次查库，结果已缓存
Listpage = 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()，避免二次遍历
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
