C++迭代器模式深度解析：从STL实现到自定义容器实战

说到C++里的迭代器模式，很多人第一反应是：这不就是STL里天天在用的东西吗？确实，C++标准库是把迭代器模式落地得最彻底的一套代码，vector有迭代器，list有迭代器，map有迭代器，连原生的数组都能用指针当迭代器用。但也正因为太常见，反而让很多人忽略了它背后的设计意图——迭代器模式到底解决了什么问题？为什么C++标准库非要搞出这么一套约定来？如果让你自己设计一个自定义容器，又该怎么把它写进去？

这篇文章我想换一个角度，不从“设计模式教科书”出发，而是从一个C++开发者的实际视角，把迭代器模式重新梳理一遍。会先讲清楚这个模式的核心价值，再给出从基础版到现代C++写法的完整实现，然后把实战中容易踩的坑整理一遍。不管你是刚学C++不久、还在搞懂begin()和end()是怎么配合的，还是已经在写业务代码、想给自定义数据结构设计通用遍历接口，这篇文章应该都能给你一些可以直接拿去用的思路。

1. 先想清楚：迭代器模式到底在解决什么问题

1.1 一个很容易被忽视的设计痛点

假设你现在要写一个“待办事项列表”，第一版用数组存数据：

struct TodoItem { string title; bool done; }; TodoItem items[100]; int itemCount = 0;

遍历的时候你是这么写的：

for (int i = 0; i < itemCount; i++) { cout << items[i].title << endl; }

一切正常，代码能跑，逻辑也直观。但问题来了：如果产品经理说“列表性能不行，要改成链式结构”，你就要把这段遍历代码全部改掉。更麻烦的是，如果这类遍历在项目里有几十处，每一处都要跟着改。也就是说，你遍历数据的代码，和“数据到底是怎么存储的”这件事，被强耦合在一起了。

迭代器模式的核心思想，就是把“怎么访问数据”和“数据内部怎么组织”拆开。客户端只跟迭代器打交道，迭代器负责把容器内部的结构细节藏起来。这样不管容器底层是连续内存、链表还是树，对调用方来说体验都是一样的：拿begin()取起点，用operator++往下走，用operator*取值。

这个思路说起来很简单，但实际价值非常大——它让你可以从“具体容器”中解脱出来，写出真正通用的代码。

1.2 C++标准库早就把答案写在脸上了

在C++标准库里，迭代器不是一个类，而是一组约定。你不需要继承某个Iterator基类，只要你的类型支持operator*、operator++、operator!=这些运算符，它就可以当迭代器用。

举个例子，这是标准库中几种完全不同底层结构的容器：

vector<int> v = {1, 2, 3}; list<int> lst = {1, 2, 3}; map<string, int> m = {{"a", 1}, {"b", 2}, {"c", 3}};

一旦你要遍历它们，代码却惊人地一致：

// vector 遍历 for (auto it = v.begin(); it != v.end(); ++it) { cout << *it << " "; } // list 遍历 for (auto it = lst.begin(); it != lst.end(); ++it) { cout << *it << " "; } // map 遍历 for (auto it = m.begin(); it != m.end(); ++it) { cout << it->first << ":" << it->second << " "; }

调用方根本不需要知道list的节点是通过指针串起来的，也不需要知道map底层是红黑树。迭代器把这些底层差异全部屏蔽掉了。更妙的是，C++11之后连这个循环都可以简化成range-for：

for (auto& item : v) { ... }

range-for底层翻译过来仍然是迭代器操作，它依赖的就是begin()和end()这一组函数的存在。换句话说，只要你给自定义容器实现了迭代器接口，它就能自动获得类似标准容器的遍历体验，甚至能直接用标准库里的排序、查找、统计等算法，这是迭代器模式在C++里最厉害的地方。

1.3 什么样的项目场景真正需要迭代器模式

不是所有的场景都需要自己写迭代器。以我个人的经验，判断标准其实很明确：

如果你只是在一个小函数里遍历一个vector，直接用下标访问最简单，别为了“设计模式”去做过度封装。但如果有下面这些情况，迭代器模式就值得认真考虑：

第一，你要设计一个自定义集合类。比如一个存放游戏单位对象的“对象池”，或者一个内部存储结构可能变化的业务容器。对外暴露统一的遍历接口，底层结构调整时调用方代码完全不用动。

第二，你需要支持多种遍历方式。比如一个二叉树，既要有前序遍历、中序遍历，还要有逆序遍历。如果把这些遍历逻辑全部塞进容器类，容器会越来越臃肿；分别实现几种迭代器，互相之间完全解耦，后续加新遍历方式也不用动原有代码。

第三，你希望自己的容器能被标准库算法直接使用。比如std::sort、std::find、std::accumulate。这些算法对迭代器有明确的等级要求，你只要让自定义迭代器满足相应的运算符约定，标准库算法就能直接操作你的数据结构。

搞清楚这些场景之后，再来看迭代器模式的核心组件和设计思路，会更容易理解它为什么要这么设计。

2. 迭代器模式的核心组件与设计思路

2.1 四个参与角色：聚合对象、迭代器、客户端、创建入口

经典的GoF设计模式定义中，迭代器模式有四个参与者：聚合对象、迭代器、客户端，以及负责创建迭代器的工厂方法。在C++里，这四个角色的分工可以这样理解：

聚合对象解决“数据存哪儿”的问题。它负责管理真正的数据集合，可以是数组、链表、树，甚至是从文件或者网络流中读取的数据源。聚合对象不需要自己提供遍历逻辑，它只需要提供数据访问能力，以及一个创建迭代器的入口。

迭代器解决“怎么遍历”的问题。它内部保存着“当前遍历到哪个位置”的状态，并提供向后移动和读取当前元素的操作。关键点在于，迭代器保存的只是一个“位置状态”，不是容器数据的一份拷贝。

客户端是使用者的角色。它只面向迭代器写代码，不直接接触容器内部的存储结构。这也是为什么客户端代码可以在底层存储改变时保持不变。

创建入口在C++里通常就是begin()和end()。它们分别负责获取指向第一个元素的迭代器和指向末尾之后位置的迭代器。末尾之后的位置不表示任何元素，它只是一个“哨兵”，用来和普通迭代器做比较，判断遍历是否结束。

这里有一个重要的细节：迭代器保存的是“遍历状态”而不是“容器快照”。换句话说，如果你在遍历过程中往容器里添加了新元素，迭代器不一定会立刻看到它，甚至可能失效。这一点在后面的问题排查部分还会详细讲。

2.2 为什么遍历逻辑不能写死在容器里

有些人可能觉得，直接在容器类里写一个forEach方法不就行了吗？为什么要专门抽出迭代器来？

原因在于单一职责原则。容器的核心职责是管理数据：谁会存、谁会取、什么时候扩容、什么时候释放。遍历则属于另一类完全不同的职责：你用什么顺序访问数据、怎么记录访问位置、遍历到什么时候结束。

如果这两种职责混在一起，容器类就会随着遍历方式的增加而膨胀。比如一个二叉树类，你给它加一个中序遍历方法，再加一个前序遍历方法，再来一个逆序遍历方法……每加一种遍历方式，都要修改容器类本身，违反开闭原则。而且同一个时刻容器只能有一种遍历状态，如果有两个线程或者两块逻辑需要同时遍历同一个容器，就会互相踩踏。

如果把遍历抽成迭代器，情况就完全不同了。每来一种需求，就写一个新的迭代器类，容器本身不动。多个迭代器同时存在、分别维护各自的遍历位置，互不干扰。从使用者的角度，拿到迭代器就像拿到一个便携式的“浏览工具”，这个工具可以随时借给不同的调用方使用。

这个设计思路和现实中的“书架与图书管理员”很像。你的书架是数据的存储位置，书的摆放方式决定了底层结构；但你去查一本书，不需要关心书架内部每一层怎么排列，只需要有一个管理员告诉你“从这里开始，沿着这个顺序，逐本往下找”。管理员就是迭代器，书架就是聚合对象。

2.3 C++迭代器的五种能力等级，为什么这么重要

C++的迭代器有一个非常独特的设计，是Java、Python等语言的迭代器概念里没有的：迭代器被分成了五个能力等级，能力从弱到强分别是：

为什么要分等级？因为不同的容器底层结构决定了它天然能支持的操作不一样。vector的数据是连续内存，所以它的迭代器可以像指针一样直接加一个数字跳到指定位置，这就是随机访问迭代器。list的节点是通过指针串起来的，想走到第5个元素必须一路走过去，因此它只能提供双向迭代器，不能随机跳转。

这个分级直接影响你写的代码能不能被标准库的某个算法接受。比如std::sort要求随机访问迭代器，你拿list的迭代器去调用std::sort，编译期就会报错。这不是坏事，它是在告诉你list的底层结构不适合排序算法，需要换一种排序方式。

理解了这个分级之后，当你自己设计容器和迭代器时就有了一个明确的目标：你的迭代器应该参照哪个等级来设计？能提供随机访问能力，就尽量提供；底层结构做不到，那就老老实实做成双向迭代器，不硬撑。这样写出来的迭代器更符合C++社区的习惯，也能被标准库算法正确识别。

3. 从基础版到现代写法：帮你逐步落地这套模式

3.1 经典GoF风格实现：先用最直白的继承方案把流程跑通

如果你想快速理解迭代器模式的原始结构，先看看经典的面向对象写法。下面这个例子是用C++实现一个简单的书架容器，书架里存放图书名称，并提供一个书架迭代器：

#include <iostream> #include <vector> #include <memory> #include <string> class Iterator { public: virtual ~Iterator() = default; virtual bool hasNext() const = 0; virtual std::string next() = 0; }; class Aggregate { public: virtual ~Aggregate() = default; virtual std::shared_ptr<Iterator> createIterator() const = 0; }; class BookShelfIterator : public Iterator { public: explicit BookShelfIterator(const class BookShelf* shelf) : m_shelf(shelf), m_index(0) {} bool hasNext() const override { return m_index < m_shelf->getCount(); } std::string next() override { return m_shelf->getBookAt(m_index++); } private: const class BookShelf* m_shelf; size_t m_index; }; class BookShelf : public Aggregate { public: void addBook(const std::string& book) { m_books.push_back(book); } size_t getCount() const { return m_books.size(); } std::string getBookAt(size_t index) const { return m_books[index]; } std::shared_ptr<Iterator> createIterator() const override { return std::make_shared<BookShelfIterator>(this); } private: std::vector<std::string> m_books; };

客户端的使用方式：

void printBooks(const BookShelf& shelf) { auto it = shelf.createIterator(); while (it->hasNext()) { std::cout << it->next() << std::endl; } }

这个写法结构清晰，完全符合GoF描述的迭代器模式。hasNext()负责判断是否还有元素，next()负责返回当前元素并推进位置。但说实话，这种基于虚函数的写法在现代C++工程中已经被很少使用了。为什么？

因为C++不是Java。Java的集合框架从设计之初就统一继承了Iterable接口，所有集合共用一套迭代器接口。但在C++这套体系里，虚函数调用是运行期多态，每次调用hasNext和next都会有一次间接跳转，性能上有损失；更重要的是，它打破了值语义，迭代器要包一层shared_ptr或者unique_ptr才能传递，用起来很不方便。

所以这个经典写法的主要意义在于教学，帮助你理解迭代器模式的角色划分。真正在工程里落地，还需要换一种更符合C++风格的实现方式。

3.2 模板化迭代器：让自定义容器也能被遍历

现代C++实现迭代器模式，核心思路不是“继承一套接口”，而是“满足一组约定”。

什么叫约定？就是只要你的类型实现了特定的运算符和成员函数，编译器就认为它是一个迭代器。对于最简单的正向迭代器，最少需要四样东西：解引用运算符operator*、递增运算符operator++、比较运算符operator!=，以及一个对应类型的别名。

下面这个例子，是我自己实现一个固定长度数组容器，并给它配上模板迭代器的完整代码：

#include <iostream> template<typename T> class FixedArray; template<typename T> class FixedArrayIterator { public: using value_type = T; using pointer = T*; using reference = T&; explicit FixedArrayIterator(pointer ptr) : m_ptr(ptr) {} reference operator*() const { return *m_ptr; } pointer operator->() { return m_ptr; } FixedArrayIterator& operator++() { ++m_ptr; return *this; } bool operator!=(const FixedArrayIterator& other) const { return m_ptr != other.m_ptr; } bool operator==(const FixedArrayIterator& other) const { return m_ptr == other.m_ptr; } private: pointer m_ptr; }; template<typename T, size_t N> class FixedArray { public: using value_type = T; using iterator = FixedArrayIterator<T>; iterator begin() { return iterator(m_data); } iterator end() { return iterator(m_data + N); } T& operator[](size_t index) { return m_data[index]; } const T& operator[](size_t index) const { return m_data[index]; } private: T m_data[N]; };

注意，这里的FixedArrayIterator是针对底层连续存储设计的，所以它内部保存一个裸指针就行。遍历容器时，可以像标准容器一样使用：

int main() { FixedArray<int, 5> arr; for (int i = 0; i < 5; i++) { arr[i] = i * i; } for (auto it = arr.begin(); it != arr.end(); ++it) { std::cout << *it << " "; } std::cout << std::endl; // 直接使用range-for for (int val : arr) { std::cout << val << " "; } std::cout << std::endl; return 0; }

这段代码能跑的关键在于三个细节：第一，begin()和end()这两个成员函数返回的是一个迭代器对象；第二，迭代器对象支持operator!=，让range-for能判断循环何时结束；第三，range-for在内部展开后会用operator!=来判断终止条件，而不是用operator<或者operator==。

这里有一个很容易踩的坑：很多人给迭代器写了operator==，却忘了写operator!=。普通代码里用it == arr.end()没问题，但range-for底层用的是it != arr.end()，如果没写operator!=，编译器会报错。

这种模板迭代器的写法，性能上更接近原生指针，没有任何虚函数开销，同时保持了接口的统一性。它也是标准库内部设计迭代器时采用的核心思路。

如果用一句话总结C++迭代器的价值，我觉得应该是：它让“如何组织数据”和“如何遍历数据”彻底解耦，但代价是你必须遵循一套严格但简单的运算符约定。

3.3 如果你的迭代器要支持标准库算法

自定义迭代器最爽的时刻，是它能直接配合标准库算法使用。比如上面那个FixedArray，如果你想对里面的元素排序，直接写：

#include <algorithm> std::sort(arr.begin(), arr.end());

但这里有一个前提：std::sort要求随机访问迭代器，它内部会用it + 5、it - it这种操作。如果FixedArrayIterator只实现了operator++和operator*，std::sort在编译期就会拒绝它。

要让迭代器支持随机访问，需要额外实现一批运算符：operator+、operator-、operator+=、operator-=、operator[]，还有operator<等比较运算符。下面是一个示例：

template<typename T> class FixedArrayIterator { public: using value_type = T; using pointer = T*; using reference = T&; using difference_type = std::ptrdiff_t; explicit FixedArrayIterator(pointer ptr) : m_ptr(ptr) {} reference operator*() const { return *m_ptr; } FixedArrayIterator& operator++() { ++m_ptr; return *this; } FixedArrayIterator operator++(int) { FixedArrayIterator tmp = *this; ++m_ptr; return tmp; } FixedArrayIterator& operator--() { --m_ptr; return *this; } FixedArrayIterator& operator+=(difference_type n) { m_ptr += n; return *this; } FixedArrayIterator& operator-=(difference_type n) { m_ptr -= n; return *this; } friend FixedArrayIterator operator+(FixedArrayIterator it, difference_type n) { it += n; return it; } friend difference_type operator-(const FixedArrayIterator& a, const FixedArrayIterator& b) { return a.m_ptr - b.m_ptr; } reference operator[](difference_type n) const { return m_ptr[n]; } bool operator!=(const FixedArrayIterator& other) const { return m_ptr != other.m_ptr; } bool operator<(const FixedArrayIterator& other) const { return m_ptr < other.m_ptr; } private: pointer m_ptr; };

写得越完整，迭代器的能力等级越高，能被标准库算法复用的范围也就越广。只实现了operator++和operator*的迭代器，只能配合std::find这种“正向单次遍历”的算法使用；补齐了随机访问能力之后，std::sort、std::binary_search这类算法就都可以直接用了。

所以在设计之前，先想清楚你的容器需要支持哪些算法，再有针对性地实现相应的运算符。从前面提到的五种迭代器能力等级出发，最低满足需求就好，不用一上来就全实现，避免过度设计。

4. 实操心得与常见问题排查

4.1 迭代器失效：C++容器使用中最经典的坑

在实战中，迭代器模式最常见的问题不是编译不过，而是运行期“迭代器失效”。迭代器失效的意思是，迭代器所指向的位置已经不再有效了，继续对它解引用或者递增，会产生未定义行为。

一个非常经典的场景是vector扩容：

std::vector<int> numbers = {1, 2, 3, 4, 5}; auto it = numbers.begin() + 2; std::cout << *it << std::endl; // 正常输出 3 numbers.push_back(6); // 发生扩容，重新分配内存 numbers.push_back(7); // 再次扩容 std::cout << *it << std::endl; // 未定义行为，it已经失效

为什么？因为vector扩容时会重新申请一块更大的内存，然后把原有元素拷贝过去，最后释放旧内存。留在旧内存里的迭代器，指向的是一块已经释放的内存，继续访问它就会读到脏数据，甚至直接程序崩溃。

list、map这类基于节点的容器相对安全一点，插入元素通常不会让已有迭代器失效，但删除当前迭代器指向的节点时，这个迭代器也会失效。

删除操作是重灾区。比如你想把vector里所有偶数删掉，如果这样写：

for (auto it = numbers.begin(); it != numbers.end(); ++it) { if (*it % 2 == 0) { numbers.erase(it); // 迭代器失效，后续++it是未定义行为 } }

这段代码第一次删除偶数之后，循环里的++it就是未定义行为了，程序可能崩溃，也可能正常运行，但结果是不可信的。

正确做法是使用erase返回的迭代器赋值给it：

for (auto it = numbers.begin(); it != numbers.end();) { if (*it % 2 == 0) { it = numbers.erase(it); // erase返回下一个有效迭代器 } else { ++it; } }

这就是C++迭代器的一个关键特点：迭代器一旦失效，后续一切操作都不安全，必须通过合法的返回值重新获得有效的迭代器。

4.2 自定义迭代器时最容易踩的编译期与运行期陷阱

自己写迭代器的时候，有很多细节不亲自试一遍很难发现。

第一个陷阱是忽略了const容器和const迭代器的区别。如果你的容器只在const对象上被访问，比如const FixedArray<int, 5>&，那么arr.begin()必须是const成员函数，并且返回的迭代器需要能解引用为const T&。否则，你无法在只读函数里遍历容器。

第二个陷阱是迭代器operator*返回了临时对象。如果你写的是：

T operator*() const { return *m_ptr; }

那就会导致每次解引用都返回一个拷贝，不仅性能差，还会让*it = x这种写操作无法编译。正确的做法是返回引用：

T& operator*() const { return *m_ptr; }

第三个陷阱是迭代器没有处理“空容器”的情况。空容器begin()和end()返回的位置相同，遍历循环一开始就不满足条件，这本身没问题。但如果你在迭代器构造函数里对指针做了“指向空位置”的处理，比如把nullptr特判成end，就要格外小心，否则空容器和非空容器在比较时会逻辑混乱。

第四个陷阱是range-for循环中的“引用悬挂”。如果容器返回的不是真正的元素，而是按值返回的代理对象，那么for (auto& item : container)会绑定到一个临时对象上，编译期就会报错。这种问题在实现一些视图类型、过滤迭代器、变换迭代器时尤其常见。

第五个陷阱是并发访问。多个线程同时往容器里写数据，再加上一个线程读数据，这种场景下即使你的迭代器实现得再完善，也无法保证线程安全。迭代器模式的线程安全问题，本质上要靠容器的并发控制机制来解决，迭代器本身只需要保证单线程场景下的逻辑正确。

4.3 什么时候该用，什么时候别硬上

讲完坑，再聊聊我个人的判断标准。

写自定义迭代器最直接的理由，是有“通用算法”的需求。如果你的容器只在一个模块内部使用，遍历逻辑只有一处，那直接用下标或者指针就够了，强行套迭代器模式反而增加代码量。但如果你希望容器可以被多个模块通过统一的方式遍历，甚至想直接配合标准库算法，那迭代器模式就是最合适的方案。

“支持多种遍历顺序”也是一个明确信号。比如你的二叉树需要前序、中序、后序三种遍历方式，用迭代器分别实现，比在容器类里堆三个方法要清晰得多。每个迭代器各自维护状态，容器本身不用改。

还有一点，如果你写的迭代器是给团队用的公共组件，务必做好文档和单元测试。至少应该覆盖这些场景：空容器遍历、单个元素容器、多个元素容器、遍历中途插入元素、遍历中途删除元素、多个迭代器同时遍历同一容器。这些测试能提前暴露迭代器失效、悬挂引用、越界访问等问题，写起来麻烦，但收益极大。

5. 最后分享一个我实际写迭代器的习惯

从我自己写自定义迭代器的经验来看，有一个习惯真的能省掉很多麻烦：在写完迭代器的第一版后，别急着塞进业务代码，先拿一个最简单的标准库算法试跑一遍。比如用std::find找出容器里某个元素，用std::count统计符合条件的元素个数。这些算法对迭代器的要求不高，但能立刻暴露最常见的几类问题——operator!=写没写、operator*返回值类型对不对、begin和end能不能正确翻译成迭代器。

另外一个习惯是，我会给迭代器内部那个指针类型定义一个明确的别名，比如using pointer = T*。这样在实现operator++、operator!=这些运算时，写起来更清晰，后续如果要修改底层存储方式，也只需要改一处。

迭代器模式的本质不是让你去背一个类的继承结构，而是理解“通过统一的访问方式解耦数据存储与遍历逻辑”这个思路。C++用一个独特的运算符约定，把这个思路打磨到了极致。把你的容器变成一个“能被标准算法操作的对象”，这本身就是一门很实用、也很值钱的功夫。