Stream.skip(n)仅按位置跳过前n个元素，不识别无效数据；分页必须先filter再skip和limit，否则有效数据不足；大数据量时skip性能差，应优先用数据库分页或List.subList()。
Stream.skip() 不能跳过“无效数据行”，它只按顺序跳过前 N 个元素
这是最常被误解的一点：Stream.skip(n) 不会过滤、不识别“无效”，它只是机械地丢弃流中前 n 个已生成的元素。如果你的列表里混着 null、空字符串、状态为 "DELETED" 的对象，skip() 对它们完全无感——它跳的是“位置”，不是“语义”。分页时想跳过无效行，必须先 filter()，再 skip() 和 limit()。
分页前务必先 filter() 再 skip()，顺序错了结果就错
比如要展示第 3 页、每页 10 条有效用户，你得：先剔除所有 user.getStatus().equals("INACTIVE") 的记录，再跳过前 20 条，再取 10 条。如果反过来——先 skip(20) 再 filter()，那被跳过的 20 个里可能包含大量无效项，实际落到第 3 页的有效数据远少于 10 条，甚至为空。
stream.filter(u -> u != null && "ACTIVE".equals(u.getStatus())).skip((page - 1) * pageSize).limit(pageSize)
skip() 在无限流或大数据源下有性能隐患
skip(n) 必须遍历并丢弃前 n 个元素，无法跳转。如果底层是数据库查询，千万别把 skip() 当成 SQL 的 OFFSET 直接套用——Java Stream 不会下推优化，它会把全量数据拉到内存再跳。真实分页应优先用数据库原生分页（如 JpaRepository.findAll(Pageable)），仅在内存集合（如 List<user></user>）做小规模预处理时才用 skip()。
- 对 10 万条内存列表调
skip(99990)，仍需遍历 99990 次 - 若数据来自
Stream.generate(...)，skip()可能触发大量无意义计算 - 并发流中
skip()行为不变，但顺序不保证，慎用于依赖严格序的分页
替代方案：用 List.subList() 更直接，但要注意边界检查
如果原始数据已经是 List（而非惰性 Stream），直接用 subList() 通常更高效、更可控，也避免了 skip() 的遍历开销：
int from = (page - 1) * pageSize;
int to = Math.min(from + pageSize, list.size());
List<User> pageData = list.stream()
.filter(u -> "ACTIVE".equals(u.getStatus()))
.collect(Collectors.toList())
.subList(from, to);注意：必须确保 from ，否则抛 <code>IndexOutOfBoundsException；subList() 返回的是原列表的视图，修改会影响原列表——如需隔离，加 new ArrayList(...) 包一层。
真正麻烦的从来不是 skip() 怎么写，而是没想清楚“无效数据”的定义是否统一、是否该在数据源头过滤、以及分页上下文到底在内存还是数据库。这些不厘清，光调对函数也没用。
