Iterator需包装为Stream才能使用filter、map等函数式操作，因Iterator仅提供基础遍历方法；标准路径是Iterator→Spliterator→Stream，通过Spliterators.spliteratorUnknownSize中转并传入StreamSupport.stream。
将 Iterator 包装为 Stream 是 Java 8 函数式编程落地的关键桥梁，尤其在已有传统迭代逻辑（如分页查询、自定义数据源、遗留集合遍历）需快速接入现代流式处理链路时，它能避免重写数据获取层，实现“零侵入式”升级。
为什么必须走这一步：Iterator 与 Stream 的能力断层
Iterator 仅提供 hasNext()、next() 和 remove() 等基础操作，无法直接 filter、map、limit 或并行处理；而 Stream 提供完整的声明式操作链、短路机制（如 findFirst）、惰性求值及并发支持。不包装就无法享受这些能力。
常见场景包括：
- 数据库分页结果集（JDBC ResultSet 封装的 Iterator）
- 第三方 SDK 返回的不可修改的 Iterator（如 Azure SDK 中的 PagedIterable）
- 手写状态机式数据生成器（如模拟传感器流、日志行迭代器）
标准转换路径：Iterator → Spliterator → Stream
Java 不提供 iterator.stream()，因为 Iterator 没有内置 spliterator() 方法。必须通过 Spliterators.spliteratorUnknownSize 中转：
Iterator<String> it = getLegacyDataIterator();
Stream<String> stream = StreamSupport.stream(
Spliterators.spliteratorUnknownSize(it, Spliterator.ORDERED),
false // false 表示串行流；true 可启用并行，但需确保数据源线程安全
);注意：
-
Spliterator.ORDERED 表明元素顺序有意义（绝大多数场景适用）；若数据无序可选
NONNULL或组合使用 - 第二个参数 parallel 控制是否启用并行流；对单线程生成的 Iterator 并行化通常无收益，反而增加开销
- 该转换是一次性消费：Iterator 被遍历后无法重用，应确保只转换一次
实战嵌入响应式流水线：与函数式操作自然衔接
包装成 Stream 后，即可无缝叠加 filter、map、collect 等操作，构成清晰的数据管道：
Iterator<User> userIterator = legacyUserService.fetchActiveUsers(); <p>List<String> emails = StreamSupport.stream( Spliterators.spliteratorUnknownSize(userIterator, Spliterator.ORDERED), false) .filter(u -> u.getStatus() == User.Status.ACTIVE) .map(User::getEmail) .distinct() .limit(100) .toList(); // Java 16+；旧版本用 collect(Collectors.toList())
这种写法已具备函数式核心特征：
- 声明式：关注“要什么”，而非“怎么取”
- 不可变：原始 Iterator 不被修改，中间结果不污染状态
- 可组合：任意环节可插入新逻辑（如加日志、异常兜底、指标埋点）
进阶：对接响应式生态（Reactor / RxJava）
若后续需接入 Project Reactor，可用 Flux.fromIterable() 作轻量桥接：
Iterator<Event> eventIt = sensorDataStream.iterator(); Iterable<Event> iterable = () -> eventIt; // 将 Iterator 包装为 Iterable <p>Flux<Event> flux = Flux.fromIterable(iterable) .filter(e -> e.getTimestamp() > System.currentTimeMillis() - 300_000) .onBackpressureBuffer(10_000);
关键点：
- 用 lambda
() -> eventIt构造匿名 Iterable，规避手动实现类 - Reactor 自动调用其
spliterator()，底层仍复用相同 Spliterator 转换逻辑 - 此时已具备背压、异步调度、错误传播等响应式能力
