迭代器模式通过分离遍历行为与容器内部结构，使容器专注数据管理、迭代器封装访问逻辑，从而避免实现细节暴露、支持多遍历方式、遵循单一职责与开闭原则，并提供统一访问接口。
因为遍历行为和内部结构属于两类不同性质的职责——一个关注“怎么走”，一个关注“存什么”。混在一起，容器就既要做数据管家，又要当路线规划师，结果两头都做不干净。
避免暴露实现细节
如果遍历逻辑写在容器类里，比如数组用索引、链表用 next 指针、树用递归栈，这些细节就会直接暴露给调用方。客户端一依赖索引或指针，容器后续想换结构（比如把链表改成跳表），所有遍历代码都得跟着改。迭代器把“怎么访问”封装在自己内部，容器只管提供数据入口，外部永远只看到 hasNext() 和 next() 这两个稳定接口。
支持多种遍历方式而不动容器
同一个容器，业务可能需要正向、逆向、层级、过滤、分页等不同遍历策略。如果遍历逻辑硬编码在容器中，每加一种方式就得改容器类，违反开闭原则。而用迭代器模式，只需新增 ConcreteIterator 子类（如 ReverseListIterator、FilteredTreeIterator），容器本身完全不用动，createIterator() 方法返回哪个迭代器，就用哪种方式遍历。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
让容器专注单一职责
容器的核心价值是组织和管理数据，不是控制访问流程。把遍历抽出去，容器类体积更小、逻辑更清晰、测试更容易。比如 ArrayList 不用操心“用户要不要跳过 null 元素”，也不用为“是否支持并发遍历”增加锁逻辑——这些都交给对应的迭代器去处理。
统一客户端访问契约
无论底层是数组、哈希表还是图结构，只要实现了 Aggregate 接口，客户端就能用完全相同的 while (it.hasNext()) { it.next() } 方式遍历。这种一致性大幅降低使用门槛，也让泛型算法（如搜索、统计、转换）可以跨容器复用，不绑定具体实现。
不复杂但容易忽略：分离不是为了炫技，而是为了让变化有边界——结构变，不影响遍历；遍历变，不牵连存储。
