在 WebFlux 中使用 skip()/take() 实现分页时，若需返回过滤后全部数据的总数（而非当前页数量），不能依赖 collectList().map(...).size()，而应先完成过滤再统一分页与计数——本文提供零阻塞、响应式友好的纯流式解决方案。
在 webflux 中使用 `skip()`/`take()` 实现分页时，若需返回**过滤后全部数据的总数**（而非当前页数量），不能依赖 `collectlist().map(...).size()`，而应先完成过滤再统一分页与计数——本文提供零阻塞、响应式友好的纯流式解决方案。
在响应式编程中，分页逻辑常被误认为可直接在 Flux 链上通过 skip() 和 take() 同时完成“切片”与“计数”。但关键限制在于：skip() + take() 仅作用于当前流片段，无法回溯已丢弃的数据，因此 customers.size() 在 .collectList() 后仅代表当前页元素个数，完全无法反映过滤后的全局总量。
正确解法是：先将过滤后的完整结果集收集为 Mono>，再在非阻塞的 map 阶段进行内存级分页与总数计算
。该方案不引入线程阻塞（如 block()），不违背响应式契约，且充分利用了 Project Reactor 的组合能力。
以下是推荐实现（以 Long 类型 ID 模拟 Customer）：
public Mono<customersresponse> getCustomers(Integer page, Integer pageSize, String filter) {
return customersService.getCustomers() // 返回 Flux<customer>
.filter(customer -> someFilterFunction(filter))
.collectList() // ✅ 关键：先收拢为 Mono<list>>
.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()); // ✅ 真实过滤后总数
});
}</customer></list></customer></customersresponse>
? 为什么不用 stream().skip().limit()？
尽管示例答案中使用了 stream().skip().limit()，但对 List 调用 .subList() 更高效（O(1) 时间复杂度，无中间流对象创建）。尤其在大数据量下，避免重复遍历和装箱开销，是更优实践。
注意事项：
- ✅ collectList() 是非阻塞操作，适用于中等规模数据（如万级以内）；若原始数据量极大（如百万级），需考虑数据库层分页 + COUNT(*) 查询，而非内存聚合；
- ✅ page 和 pageSize 应做边界校验（如 page
- ❌ 避免在 map() 外调用 block() 或 toFuture().get()，否则破坏响应式链路，导致线程池饥饿；
- ✅ 若 customersService.getCustomers() 底层支持 SQL 分页（如 Spring Data R2DBC），建议优先使用 Pageable + Mono
>，由框架自动处理总数查询（如 COUNT 子查询）。
最终，CustomersResponse 建议采用不可变或 Fluent 风格设计，提升 API 可读性与线程安全性：
@Data
@Accessors(fluent = true, chain = true)
public static class CustomersResponse {
private List<customer> items = Collections.emptyList();
private int totalCount = 0;
}</customer>
此方案平衡了响应式语义、代码可维护性与运行时效率，是 WebFlux 分页场景下获取真实总数的推荐范式。
