Java Stream API 的 skip() 不适合高性能游标分页，因其每次分页仍需从头遍历跳过前 n 项，时间复杂度 O(n+m)，无法保持状态或复用位置；真正高效分页应依赖数据源的游标/键值定位能力，Stream 仅封装单批结果。
Java Stream API 本身不支持“动态截断”或“游标式分页”，skip() 是惰性操作，但无法真正提升大数据量分页性能。它适合小规模数据的简单跳过，但在真实分页场景（如数据库游标、海量日志流）中，直接用 skip(n) + limit(m) 做分批读取会导致 O(n+m) 时间复杂度——每次都要从头遍历跳过前 n 项，越往后越慢。
为什么 skip 不适合高性能游标分页
skip() 不会改变原始数据源，只是在流管道中插入一个跳过前 N 个元素的中间操作。对基于集合的 Stream（如 list.stream()），它本质是顺序遍历丢弃；对无限流或 I/O 流（如文件行流），它仍需逐个消费直到跳过目标数——无法跳过物理存储位置，也无法复用上次结束位置。
- 第 1 页：skip(0).limit(100) → 遍历 100 项
- 第 100 页：skip(9900).limit(100) → 遍历 10000 项，其中 9900 项被丢弃
- 没有状态保持，无法“记住”上一批最后处理到哪
真正的游标分页应依赖数据源自身能力
高性能分页的关键不是 Stream 操作，而是让底层数据源支持基于游标（cursor）或键值（keyset）的定位读取，Stream 只负责封装结果：
- 数据库分页：用 WHERE id > last_id ORDER BY id LIMIT 100，而非 OFFSET（避免 skip 的线性扫描）
- 消息队列/日志系统：用 offset/timestamp/cursor 标识位置，每次请求从该位置开始拉取
- 文件按块读取：用 RandomAccessFile 或 NIO 的 position 定位，跳过已处理字节，再读下一段
此时 Stream 可作为轻量封装：把每次拉取的 List 或 Iterator 转成 Stream 处理，但分页逻辑不在 Stream 内部。
立即学习“Java免费学习笔记（深入）”；
如何用 Stream 配合外部游标做高效分批
可以封装一个“游标感知”的流生成器，把分页逻辑外置，Stream 仅负责单批处理：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
// 示例：基于主键的数据库游标分页（伪代码）
long cursor = 0;
while (true) {
List<Record> batch = queryByCursor(cursor, 100); // SQL: WHERE id > ? ORDER BY id LIMIT 100
if (batch.isEmpty()) break;
<pre class="brush:php;toolbar:false;">batch.stream()
.filter(r -> r.isValid())
.map(Record::toDto)
.forEach(processor::handle);
cursor = batch.get(batch.size() - 1).getId(); // 更新游标}
这里 Stream 只作用于当前批次，无 skip 开销，且游标可持久化、可中断恢复。
替代 skip 的轻量级流切片技巧（仅限内存小数据）
若确实在内存 List 上做简单分页（如配置项、测试数据），可用 subList 避免 skip 性能陷阱：
- 用
list.subList(fromIndex, Math.min(fromIndex + size, list.size()))直接获取子列表 - 再对其调用
.stream()—— O(1) 切片，无遍历开销 - 比
list.stream().skip(n).limit(m)更快，尤其对大 list 后续页
注意：subList 返回的是原 list 的视图，修改会影响原 list；如需隔离，可加 new ArrayList(...)。
Stream 的 skip 是语义工具，不是分页引擎。高性能游标分页的核心永远在数据源和查询策略，Stream 只是加工管道的一环。别让它承担它设计之外的责任。
