企业官网建设流程全解析

1. 这不是“背概念”，而是给遍历操作装上可插拔的引擎

迭代器模式这个词，一听到就容易让人想到教科书里那张UML类图、几个带箭头的方框，还有“提供一种方法顺序访问一个聚合对象中各个元素”的标准定义。但我在带某高校软件工程实训课时发现，学生抄完代码、默完接口，一到真实项目里写个列表遍历逻辑，还是习惯性地直接用for循环套索引——不是不会，是根本没意识到“遍历”这件事本身，其实可以被抽象成一个独立、可复用、甚至可替换的模块。

这恰恰就是迭代器模式最常被误解的地方：它不是教你怎么遍历，而是帮你把“怎么遍历”这个动作，从具体的数据结构里彻底剥离开。就像你开车，不需要知道发动机活塞怎么运动、变速箱齿轮怎么咬合，只要踩油门、打方向就行；迭代器模式就是给你的代码装上了一套标准化的“油门+方向盘”——无论背后是数组、链表、树、数据库游标，还是某个自定义的嵌套配置文件解析器，你调用的永远是next()、hasNext()、reset()这几个稳定接口。数据结构变了，遍历逻辑不用动；遍历规则要改（比如改成倒序、跳过空值、加权限校验），只换一个迭代器实现，原业务代码纹丝不动。

我参与过的某跨平台图像处理Demo里，核心模块需要批量读取本地相册、云存储桶、甚至实时摄像头帧流。最初三个地方各自写三套while循环+索引管理，结果云存储API升级后返回结构微调，两处遍历逻辑全崩。后来我们统一抽成迭代器接口，本地相册用FileIterator，云存储用CloudObjectIterator，摄像头用FrameStreamIterator，上层业务代码只认ImageSourceIterator这个抽象，后续新增NFS挂载目录支持，只加了一个新迭代器类，主流程一行代码没改。这种解耦带来的稳定性，远比“记住模式名字”重要得多。

关键词“设计模式学习笔记（十九）：迭代器模式”里的“十九”，不是凑数——它意味着你已经走过单例、工厂、观察者这些更易感知的模式，现在正站在“行为型模式”的深水区入口。这里不再解决“创建谁”或“通知谁”，而是聚焦“怎么协作”“怎么流转”“怎么控制过程”。迭代器模式正是其中最朴素也最锋利的一把刀：它不创造新功能，却让已有功能的组织方式发生质变。适合正在重构老系统、需要对接多数据源、或者写SDK/框架希望降低使用者心智负担的开发者。哪怕你现在只写CRUD接口，理解它，也能让你下一次写分页查询时，本能地把“查第一页”“查下一页”“重置游标”这些动作，封装成一个可复用的对象。

2. 为什么非得用迭代器？手写for循环到底差在哪

很多人觉得：“我for循环写得飞起，为啥要绕这么大弯子？”这个问题特别实在，我也曾这么想。直到在某公司做支付对账模块时，被一个看似简单的“逐条核对交易流水”需求逼到墙角。当时有三类数据源：MySQL里的订单表（按时间分库分表）、Redis缓存的实时流水（按商户ID哈希）、以及第三方支付网关的API（分页拉取，每页50条）。业务逻辑要求：对每个商户，先比对缓存和DB，再比对DB和网关，最后生成差异报告。

最初方案是三个地方各写一套while循环：

// MySQL部分（伪代码） ResultSet rs = stmt.executeQuery("SELECT * FROM order_2024 WHERE merchant_id = ?"); while (rs.next()) { Order order = new Order(rs); // 核对逻辑... } // Redis部分 List<String> cacheKeys = redis.keys("order:*:merchant_123"); for (String key : cacheKeys) { String json = redis.get(key); Order order = parse(json); // 核对逻辑... } // 网关API部分 int page = 1; do { List<Order> apiOrders = gateway.fetchOrders(merchantId, page++, 50); for (Order order : apiOrders) { // 核对逻辑... } } while (!apiOrders.isEmpty());

问题立刻爆发：

• 逻辑重复：三段代码里，“取出一条订单→解析→执行核对→记录结果”这个核心链条，90%内容完全一致，只是数据获取方式不同；
• 状态难统一：DB用ResultSet的游标，Redis用List索引，API用页码参数，想实现“暂停核对→人工介入→继续从断点跑”，得为每种数据源单独维护状态，成本爆炸；
• 扩展地狱：老板突然说“还要接入区块链存证的交易哈希”，你得再抄一遍循环体，再加一套状态管理；
• 测试噩梦：每新增一种数据源，就要重写所有核对逻辑的单元测试，覆盖率永远差一块。

迭代器模式的解法，本质是把“数据获取”和“业务处理”切成两半：

• 左半边（迭代器）：专注一件事——按需提供下一条数据。它封装了所有脏活：连接池管理、分页计算、缓存穿透防护、异常重试、游标偏移。对外只暴露next()（拿数据）、hasNext()（还有吗）、reset()（从头来）三个方法。
• 右半边（业务代码）：只关心“拿到数据后做什么”。它完全不知道数据来自哪，只调用迭代器接口。

这样拆分后，上面那个对账模块的主流程变成：

public void reconcileAllSources(String merchantId) { // 三种数据源，各自提供符合同一接口的迭代器 Iterator<Order> dbIterator = new DbOrderIterator(merchantId); Iterator<Order> cacheIterator = new CacheOrderIterator(merchantId); Iterator<Order> apiIterator = new ApiOrderIterator(merchantId); // 统一的核对逻辑，与数据源彻底解耦 reconcile(dbIterator, cacheIterator, apiIterator); }

而reconcile()方法内部，只用while (iterator.hasNext()) { Order o = iterator.next(); ... }这一种写法贯穿始终。新增区块链数据源？只需实现BlockchainOrderIterator，主流程零修改。想加日志？在迭代器next()方法里统一埋点，所有数据源日志格式自动一致。

这就是迭代器模式不可替代的价值：它用极小的抽象成本（就一个接口、几个方法），换取了巨大的维护弹性。它不解决“能不能做”，而是解决“好不好改、容不容易错、扩起来难不难”。在真实项目里，后者往往比前者重要十倍。

3. 手把手实现一个生产级迭代器：从基础骨架到防坑细节

很多教程只讲Iterator<T>接口的hasNext()、next()、remove()三个方法，但实际落地时，光这三点远远不够。我整理了过去五年在多个项目中沉淀的迭代器实现要点，按优先级排序，全是血泪教训。

3.1 基础骨架：必须包含的四个核心组件

一个真正可用的迭代器，绝不是简单包装一个List。它至少需要四个角色协同工作：

1. 聚合接口（Aggregate）：定义“谁可以被遍历”。例如OrderSource接口，声明createIterator()方法。这是迭代器的“雇主”，告诉外界“我支持被遍历”。
2. 迭代器接口（Iterator）：定义“怎么遍历”。标准hasNext()、next()是底线，但生产环境强烈建议加上reset()（重置到起点）、getCurrentIndex()（当前位置，用于调试）、isExhausted()（是否已遍历完，比!hasNext()语义更清晰）。
3. 具体聚合类（ConcreteAggregate）：比如DbOrderSource，它持有真实数据（如JDBC Connection），并负责创建对应的迭代器实例。
4. 具体迭代器类（ConcreteIterator）：比如DbOrderIterator，它才是真正干活的——它知道如何用SQL分页、如何处理ResultSet、如何管理数据库连接生命周期。

关键点在于：聚合类不负责遍历逻辑，只负责“生孩子”（创建迭代器）；迭代器类不持有聚合数据，只持有遍历所需的最小上下文（如当前页码、SQL参数、连接句柄）。这种分离，是避免内存泄漏和线程安全问题的基石。

3.2 参数设计：分页不是数字，而是策略

几乎所有涉及数据库或API的迭代器，都绕不开分页。但直接把pageSize=100硬编码进迭代器，是新手最大陷阱。正确做法是将分页抽象为策略：

// 分页策略接口 public interface PaginationStrategy { int getPageSize(); long getCurrentOffset(); void advanceToNextPage(); boolean isLastPage(); } // 具体策略：基于偏移量的分页（适合MySQL LIMIT offset, size） public class OffsetPagination implements PaginationStrategy { private int pageSize = 100; private long currentOffset = 0; @Override public void advanceToNextPage() { this.currentOffset += this.pageSize; } // ...其他方法 } // 具体策略：基于游标的分页（适合Redis SCAN、MongoDB cursor） public class CursorPagination implements PaginationStrategy { private String cursor = "0"; @Override public void advanceToNextPage() { this.cursor = getNextCursorFromLastResponse(); // 从上次响应中提取 } // ...其他方法 }

这样设计的好处是：当DB从MySQL迁移到TiDB（推荐游标分页），或API从REST换成GraphQL（分页参数名从page变成first），你只需替换分页策略实现，DbOrderIterator的核心遍历循环体（while(hasNext){next()}）完全不用碰。我在某电商后台迁移时，靠这套策略，三天内完成了全部17个数据源的分页适配，零业务逻辑修改。

3.3 状态管理：别让迭代器变成“状态黑洞”

迭代器必须明确回答一个问题：“我的状态存在哪？”常见错误是把状态（如当前页码、缓存列表）全堆在迭代器实例变量里，导致两个严重问题：

• 线程不安全：如果同一个迭代器实例被多个线程同时调用next()，状态必然错乱。解决方案：迭代器必须是无状态的，或每次调用都重新计算状态。例如DbOrderIterator的next()方法，应该每次调用都根据当前页码生成新SQL、开新Connection、执行新查询，而不是复用旧ResultSet。
• 资源泄漏：数据库连接、文件句柄、网络Socket，如果在迭代器构造时就打开，next()里不关闭，遍历中途异常退出，资源就永远卡死。正确姿势：资源在next()方法内申请，在方法结束前释放。用try-with-resources确保万无一失：

@Override public Order next() { if (!hasNext()) { throw new NoSuchElementException(); } try (Connection conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(buildQuerySql()); ResultSet rs = ps.executeQuery()) { if (rs.next()) { return mapToOrder(rs); } else { // 当前页无数据，推进到下一页 paginationStrategy.advanceToNextPage(); return next(); // 递归调用，获取下一页第一条 } } catch (SQLException e) { throw new RuntimeException("Failed to fetch next order", e); } }

这段代码里，Connection、PreparedStatement、ResultSet全在next()方法作用域内创建和销毁，绝不跨调用生命周期。即使next()抛出异常，try-with-resources也会自动关闭所有资源。这是保障服务长稳运行的铁律。

3.4 异常处理：别让一条脏数据毁掉整个流程

真实数据永远比想象脏。某次线上事故，就是因为第三方API返回了一条JSON字段缺失的订单，mapToOrder(rs)解析失败，next()抛出NullPointerException，上层while(hasNext)循环直接中断，导致当天对账任务只跑了前10%，财务部门半夜打电话。

迭代器必须内置“脏数据隔离”能力。标准做法是在next()里捕获所有业务异常，记录告警日志，然后跳过该条数据，继续返回下一条：

@Override public Order next() { while (true) { try { // 尝试获取下一条 if (!hasNext()) { throw new NoSuchElementException(); } // ... 数据获取和解析逻辑 return parsedOrder; } catch (ParseException | SQLException e) { // 记录详细日志：数据源、页码、原始数据片段 logger.warn("Skip invalid order at page {}, cause: {}", paginationStrategy.getCurrentPage(), e.getMessage()); // 推进到下一页/下一条，继续尝试 paginationStrategy.advanceToNextPage(); } } }

这个while(true)循环是迭代器的“韧性内核”。它保证：除非数据源彻底不可用（hasNext()返回false），否则next()方法永不失败。业务代码可以放心调用，不必在每一层都写try-catch。我在金融风控系统里强制推行此规范，上线后因数据质量问题导致的批处理中断率下降了98%。

4. 迭代器模式的实战演进：从单数据源到复杂流式处理

迭代器模式的生命力，远不止于“遍历一个List”。它的核心思想——“提供统一接口访问不同数据源”——在现代架构中正不断进化。我结合几个典型场景，展示它是如何应对真实挑战的。

4.1 场景一：多数据源合并迭代（MergeIterator）

业务需求：用户搜索时，需要同时从商品库（MySQL）、促销活动（Redis）、用户历史行为（Kafka Topic）中拉取相关数据，按相关度分数合并排序后返回Top20。

传统做法是分别查三份数据，内存里合并排序。但商品库可能返回10万条，Kafka可能有百万级历史事件，全加载进内存OOM是分分钟的事。

用迭代器模式，我们构建一个MergeIterator：

public class MergeIterator<T extends Comparable<T>> implements Iterator<T> { private final PriorityQueue<PeekableIterator<T>> heap; private final List<PeekableIterator<T>> iterators; public MergeIterator(List<Iterator<T>> sources) { this.iterators = sources.stream() .map(PeekableIterator::new) .collect(Collectors.toList()); this.heap = new PriorityQueue<>((a, b) -> a.peek().compareTo(b.peek())); // 预热：每个迭代器取第一条，放入堆 for (PeekableIterator<T> it : iterators) { if (it.hasNext()) { heap.offer(it); } } } @Override public T next() { PeekableIterator<T> top = heap.poll(); T result = top.next(); // 如果该迭代器还有下一条，放回堆，参与下次排序 if (top.hasNext()) { heap.offer(top); } return result; } @Override public boolean hasNext() { return !heap.isEmpty(); } }

这里的关键创新是PeekableIterator（可预览迭代器）：它能peek()看下一条而不消耗，确保合并排序时能准确比较。MergeIterator本身不持有任何数据，只维护一个最小堆，每次next()只从堆顶迭代器取一条，再把它“可能存在的下一条”推回堆。内存占用恒定O(N)，N是数据源数量（这里是3），与数据总量无关。我们在某电商平台搜索服务中应用此方案，QPS提升3倍，GC停顿减少70%。

4.2 场景二：流式计算迭代器（StreamIterator）

当数据源是无限流（如Kafka、WebSocket实时消息），hasNext()永远返回true，传统迭代器会陷入死循环。这时需要引入“终止条件”和“背压控制”。

我们设计StreamIterator，增加stopWhen()和throttle()方法：

public class StreamIterator<T> implements Iterator<T> { private final KafkaConsumer<String, String> consumer; private final String topic; private final AtomicBoolean stopped = new AtomicBoolean(false); private final RateLimiter rateLimiter; // Guava RateLimiter public StreamIterator(KafkaConsumer<String, String> consumer, String topic, int maxRatePerSecond) { this.consumer = consumer; this.topic = topic; this.rateLimiter = RateLimiter.create(maxRatePerSecond); } // 外部可调用，优雅停止 public void stop() { this.stopped.set(true); this.consumer.close(); // 清理资源 } @Override public T next() { if (stopped.get()) { throw new NoSuchElementException("StreamIterator has been stopped"); } // 背压：每取一条，等待指定时间 rateLimiter.acquire(); // 拉取Kafka消息（简化版） ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100)); if (records.isEmpty()) { return next(); // 无消息，继续轮询 } return parseFirstRecord(records); } @Override public boolean hasNext() { return !stopped.get(); // 流式场景，永远有下一条，除非被停止 } }

这个迭代器把“流控”和“生命周期管理”作为一等公民。业务代码可以这样用：

try (StreamIterator<Event> eventIterator = new StreamIterator<>(consumer, "user_events", 100)) { // 设置超时：最多处理10分钟 ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor(); scheduler.schedule(() -> eventIterator.stop(), 10, TimeUnit.MINUTES); // 安心遍历，不用担心OOM或无限循环 while (eventIterator.hasNext()) { Event event = eventIterator.next(); process(event); } }

4.3 场景三：组合式迭代器（CompositeIterator）

当数据结构本身是嵌套的（如树形菜单、XML文档、JSON Schema），单一迭代器难以表达层级关系。此时用组合模式+迭代器，构建CompositeIterator：

public interface TreeIterator<T> extends Iterator<T> { // 返回当前节点的深度（根节点为0） int getDepth(); // 返回当前节点是否为叶子节点 boolean isLeaf(); } public class CompositeTreeIterator<T> implements TreeIterator<T> { private final Deque<TreeNode<T>> stack = new ArrayDeque<>(); public CompositeTreeIterator(TreeNode<T> root) { if (root != null) { stack.push(root); } } @Override public T next() { TreeNode<T> node = stack.pop(); // 深度优先：先压入子节点（逆序，保证左子树先遍历） if (node.getChildren() != null) { Collections.reverse(node.getChildren()); node.getChildren().forEach(stack::push); } return node.getData(); } @Override public boolean hasNext() { return !stack.isEmpty(); } @Override public int getDepth() { // 实际实现需在栈中维护深度信息，此处简化 return calculateCurrentDepth(); } }

这种迭代器让“遍历树”变得和“遍历数组”一样简单。在某CMS系统的内容发布流程中，我们用它统一处理“文章→章节→段落→图片”的嵌套结构，模板渲染引擎只需调用while(iterator.hasNext()){render(iterator.next());}，无需关心底层是扁平化存储还是树形存储。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

迭代器模式看似简单，但实际落地时，90%的问题都出在边界条件和隐含假设上。我把这些年踩过的坑、团队新人常问的问题，整理成速查表，并附上真实排查过程。

5.1 典型问题速查表

5.2 真实排坑案例：一次深夜告警的溯源

背景：某支付系统凌晨2点触发CPU 95%告警，线程dump显示大量线程阻塞在DbOrderIterator.next()的ResultSet.next()调用上。

排查过程：

1. 第一步：确认是否死锁
   查看线程dump，发现所有阻塞线程都在等待同一个数据库连接（com.mysql.cj.jdbc.ConnectionImpl），但没有线程在持有它。说明不是Java层死锁，是数据库连接被占住。

2. 第二步：检查连接池
   jstat -gc显示GC正常，jmap -histo没发现大对象。登录Druid监控台，发现活跃连接数=最大连接数=20，且所有连接的lastActiveTime都是2小时前——连接被借出后，从未归还。

3. 第三步：定位泄露点
   在DbOrderIterator.next()方法前后加日志：

   logger.info("Before next(), conn hash: {}", conn.hashCode()); // ... ResultSet操作 logger.info("After next(), conn hash: {}", conn.hashCode());

   日志显示：Before next()有日志，After next()日志缺失。说明next()方法在ResultSet.next()时卡住了，且未进入finally块关闭连接。

4. 根因分析：
   ResultSet.next()卡住，是因为MySQL的wait_timeout（默认8小时）已过，连接被服务端关闭，但客户端未感知，仍试图读取。而我们的next()方法里，try-with-resources只包裹了PreparedStatement和ResultSet，没包裹Connection！Connection是外部传入的，next()方法结束后，Connection依然被迭代器实例持有，却未归还给连接池。

5. 修复方案：

   • 迭代器不再接收外部Connection，改为自己管理：在next()内通过dataSource.getConnection()获取，用try-with-resources确保关闭；
   • 或更优：迭代器只负责逻辑，Connection由调用方（如Service）管理，迭代器改为接受Supplier<Connection>，由调用方控制生命周期。
     我们选择了后者，因为更符合“职责分离”原则。修复后，凌晨告警消失。

这个案例揭示了一个关键原则：迭代器的资源管理边界，必须和它的生命周期严格对齐。它不该持有任何超出单次next()调用所需的资源。

5.3 新人必问三连答

Q1：remove()方法到底要不要实现？
A：99%的场景，不要实现。remove()语义是“删除刚刚next()返回的那条”，但在数据库、API、流式数据源中，删除操作和遍历操作是完全不同的权限、事务、性能模型。强行实现会导致：① 误删风险（业务代码调用remove()以为只是跳过）；② 性能灾难（每次next()都要开事务）；③ 语义混乱（remove()成功后，hasNext()是否还返回true？）。标准做法：remove()直接抛UnsupportedOperationException，并在Javadoc里明确注明“本迭代器不支持删除操作”。

Q2：迭代器能序列化吗？
A：不能，也不该。序列化迭代器意味着序列化它的所有状态（连接、游标、缓存），这在分布式环境下毫无意义，且极易引发NotSerializableException。如果需要“保存遍历进度”，应序列化分页参数（如currentPage=5, pageSize=100）或游标值（如cursor="abc123"），由反序列化后的迭代器用这些参数重建状态。这才是正确的“进度持久化”。

Q3：Spring Bean里能注入迭代器吗？
A：绝对不行。Spring Bean默认单例，如果把DbOrderIterator声明为@Service，它会被所有请求共享，内部状态（currentOffset）瞬间崩溃。正确姿势：迭代器是无状态工具类，或方法局部变量。Spring容器只管理它的依赖（如DataSource），不管理迭代器实例本身。你可以写一个IteratorFactory，在Service里调用factory.createDbIterator(params)，这才是安全的。

6. 迭代器模式的延伸思考：当它遇上函数式编程与响应式流

迭代器模式诞生于面向对象时代，但它的核心思想——“按需提供数据”——在函数式编程和响应式流（Reactive Streams）中得到了更极致的演绎。理解这种演进，能帮你跳出模式本身，看到数据处理范式的变迁。

6.1 从Iterator到Stream：惰性求值的升华

Java 8 的StreamAPI，本质上是迭代器模式的函数式升级。对比一下：

// 传统迭代器（命令式） Iterator<Order> iterator = new DbOrderIterator("M123"); while (iterator.hasNext()) { Order order = iterator.next(); if (order.getAmount() > 1000) { sendAlert(order); } } // Stream（声明式） dbOrderStream("M123") .filter(order -> order.getAmount() > 1000) .forEach(this::sendAlert);

区别在哪？

• 控制权转移：迭代器模式中，业务代码（while循环）掌握主动权，决定何时取下一条；Stream中，filter、map等操作符是“被动注册”，forEach才真正触发数据流动。
• 组合性：Stream的filter().map().sorted()可以无限链式组合，每个操作符都是一个独立的、可复用的“迭代器增强器”；传统迭代器要实现同样功能，得写FilteringIterator、MappingIterator，组合起来代码爆炸。
• 惰性求值：Stream的中间操作（filter,map）不立即执行，只有终端操作（forEach,collect）才触发。这和迭代器的hasNext()/next()按需加载一脉相承，但Stream把这种惰性封装得更透明。

所以，Stream不是迭代器的替代品，而是它的高阶抽象。当你需要简单遍历，Iterator轻量直接；当你需要复杂的数据转换流水线，Stream是更优选择。二者可以共存：StreamSupport.stream(iterator.spliterator(), false)能把任何迭代器转成Stream。

6.2 从Iterator到Flux：响应式流的异步化

当数据源是网络IO、数据库查询、消息队列时，Iterator.next()的阻塞式调用就成了性能瓶颈。Project Reactor 的Flux，则把迭代器的“拉取”（Pull）模型，升级为“推送”（Push）模型：

// 迭代器：你问我，我才给（Pull） Iterator<Order> iter = createIterator(); while (iter.hasNext()) { Order order = iter.next(); // 阻塞等待 process(order); } // Flux：我准备好就推给你（Push），你用回调处理 Flux<Order> flux = createFlux(); flux.filter(order -> order.getAmount() > 1000) .doOnNext(this::process) .onErrorResume(e -> logError(e)) .blockLast(); // 阻塞等待完成（仅测试用）

Flux的核心优势：

• 非阻塞IO：createFlux()内部用Netty或Reactor Netty，网络请求不阻塞线程，一个线程可处理数千并发连接；
• 背压支持：下游处理慢时，Flux能自动减缓上游数据推送速度，避免内存溢出；
• 错误恢复：onErrorResume、retryWhen等操作符，让错误处理变得声明式、可组合。

但这不意味着迭代器过时了。Flux的学习曲线陡峭，调试困难，而迭代器简单、直观、易于测试。我的经验是：IO密集型、高并发、低延迟场景，首选Flux；CPU密集型、逻辑复杂、需要精确控制流程的场景，迭代器仍是首选。二者不是非此即彼，而是互补。某实时风控系统中，我们用Flux处理Kafka消息流，用Iterator处理内存中的规则匹配树，各司其职。

6.3 未来趋势：迭代器与AI数据管道的融合

最近在参与一个AI训练数据准备项目，发现迭代器模式正在悄然融入AI工程。训练数据通常来自多个异构源：CSV文件、数据库、API、甚至PDF扫描件。传统做法是写脚本把所有数据ETL进一个大文件，再喂给训练框架。但数据量太大（PB级），ETL耗时数天，且无法支持在线学习。

我们的方案是：为每种数据源编写DataIterator，它们共同实现TrainingDataIterator接口：

public interface TrainingDataIterator extends Iterator<Sample> { // 返回当前批次的元数据，供采样器决策 DataStats getStats(); // 支持动态调整采样率（在线学习需要） void setSamplingRate(double rate); }

然后，训练框架的DataLoader不再关心数据来源，只调用iterator.next()获取Sample。更进一步，我们开发了WeightedMergeIterator，根据getStats()返回的数据质量分、新鲜度，动态调整各数据源的采样权重。今天多采数据库的新订单，明天多采API的用户反馈，全由算法实时调控。

这印证了迭代器模式的终极价值：它不是一个过时的“设计模式”，而是一种数据访问的契约精神——只要遵守next()/hasNext()的约定，上层就可以自由组合、替换、增强数据流。无论是1995年的GoF书籍，还是2024年的AI训练框架，这个契约从未改变，只是实现方式在进化。

我在实际使用中发现，真正吃透迭代器模式的人，写代码时会不自觉地问：“这个数据获取逻辑，能不能被抽象成一个迭代器？”这个问题本身，就是模式内化的标志。它不追求炫技，而是在日复一日的CRUD中，默默为你筑起一道可维护、可扩展、可演进的护城河。