本文介绍在 Spring WebFlux 中使用 skip()/take() 实现分页时，如何高效、非阻塞地获取应用过滤条件后的真实总记录数，避免仅返回当前页大小的错误统计。
本文介绍在 spring webflux 中使用 `skip()`/`take()` 实现分页时，如何高效、非阻塞地获取**应用过滤条件后的真实总记录数**，避免仅返回当前页大小的错误统计。
在响应式编程中，直接对 Flux
根本原因在于：skip() 和 take() 是惰性操作，它们不改变上游数据源的规模；而 collectList() 是终端操作，但若放在 skip()/take() 之后，则只收集了已截取的子集。因此，必须先完成过滤与全量收集，再进行内存级分页计算。
幸运的是，Flux.collectList() 返回的是 Mono>，它本身是非阻塞的，并不会引入线程阻塞或违背响应式契约。我们可在此 Mono 上安全执行后续的 Java Stream 分页逻辑：
public Mono<CustomersResponse> getCustomers(Integer page, Integer pageSize, String filter) {
return customersService.getCustomers() // Flux<Customer>
.filter(customer -> someFilterFunction(filter)) // 应用业务过滤
.collectList() // ✅ 关键：先收集成完整列表（非阻塞）
.map(allFiltered -> {
int fromIndex = Math.max(0, page * pageSize);
int toIndex = Math.min(fromIndex + pageSize, allFiltered.size());
List<Customer> currentPage = allFiltered.subList(fromIndex, toIndex);
return new CustomersResponse()
.items(currentPage)
.totalCount(allFiltered.size()); // ✅ 真实总数量
});
}? 优化提示：使用 subList() 比 stream().skip().limit().toList() 更高效（避免重复遍历），且语义更清晰；同时注意边界处理（如 Math.max/min），防止索引越界。
注意事项与最佳实践
- 性能权衡：该方案将过滤后的全部数据加载到内存中再分页。适用于中等数据量（例如万级以内）或数据库层已做初步分片的场景。若数据量极大（如百万级），应优先考虑数据库原生分页（如 COUNT(*) OVER() 或两次查询），而非纯内存分页。
- 空值与参数校验：务必对 page、pageSize 做合法性校验（如 page >= 0, pageSize > 0 && pageSize
- 响应式链完整性：整个流程保持 Mono 返回类型，未调用 .block()，完全符合 WebFlux 的非阻塞范式。
- 可测试性增强：如示例测试所示，block() 仅用于单元测试断言，生产代码中绝不应出现。
综上，虽然 WebFlux 强调“流式处理”，但在分页元数据需求明确的场景下，“先收全、再分页”是一种简洁、可靠且符合响应式精神的实现方式——它用一次轻量级内存聚合，换来了语义正确性与开发效率的双重提升。
