C++使用STL容器迭代器失效情况
在 C++ 开发中，STL（标准模板库）几乎是每一个开发者的“标配”。无论是 vector、map、unordered_map，还是 set、deque，STL 容器提供了高效、灵活、易用的数据结构接口。
其中最常用的操作方式之一就是通过**迭代器（iterator）**来遍历和操作容器。
但是，一旦涉及到对容器的修改操作，如果你还在用之前获得的迭代器，那就要当心了。因为你很可能已经遇到了**迭代器失效（iterator invalidation）**问题。
一、什么是“迭代器失效”？
简单说：容器内容发生变化后，原先获取的迭代器就可能变得不可用或行为未定义。
失效的迭代器表面看起来还可以使用，但实际上：
-
它可能指向已经释放的内存；
-
它可能不再指向当前容器的合法位置；
-
它可能让你的程序在运行时崩溃，甚至逻辑错误却难以察觉。
二、最典型的情况：vector 扩容时
std::vector<int> v = {1, 2, 3};
auto it = v.begin();
v.push_back(4);
std::cout << *it << std::endl; // 小心，这里可能已经失效了
vector 是一个动态数组，内部连续存储。当你调用 push_back 时，如果当前容量不足，它会重新分配一块更大的内存，把原有元素搬过去。
这时，原先的迭代器 it 指向的是原始的那块内存，已经被释放了。你再使用 *it，就是典型的悬空引用。
三、哪些 STL 容器容易导致迭代器失效？
下面是一些常见 STL 容器及它们在修改操作下的迭代器稳定性总结：
| 容器 | 插入操作是否导致迭代器失效 | 删除操作是否导致迭代器失效 |
|---|---|---|
vector | 是（扩容时全部失效） | 是（删除位置后的全部失效） |
deque | 是（头尾插入都可能失效） | 是（被删除元素后失效） |
list | 否 | 是（仅删除位置处失效） |
map / | 否（插入不失效） | 是（删除元素本身失效） |
unordered_* | 是 | 是 |
可以看到，list、map 和 set 在多数操作下都比较安全，而 vector 和 deque 就需要小心了。
四、一个真实常见的坑：边遍历边删除
std::vector<int> v = {1, 2, 3, 4, 5};for (auto it = v.begin(); it != v.end(); ++it) {if (*it % 2 == 0) {v.erase(it); // 问题：erase后 it 已经失效了}
}
这段代码执行后结果不可预测，轻则漏删元素，重则直接崩溃。正确的做法是使用 erase 的返回值：
for (auto it = v.begin(); it != v.end(); ) {if (*it % 2 == 0) {it = v.erase(it); // 正确做法，erase 返回的是下一个有效迭代器} else {++it;}
}
五、一些建议和规避方法
1. 修改容器时避免持有旧迭代器
尤其是调用 push_back、insert、erase 等操作之后，不要继续使用之前获取的迭代器，除非你能确定它仍然有效。
2. 优先使用返回值
很多 STL 的修改函数（如 erase, insert）都会返回一个新的迭代器，你应该用这个返回值继续操作，而不是依赖原始迭代器。
3. 使用稳定容器处理插删逻辑
如果你的应用场景中需要频繁插入或删除元素，推荐使用 list、map 等迭代器相对稳定的容器，避免频繁失效。
4. 理解容器的实现机制
理解容器底层结构（比如 vector 是连续内存，list 是双向链表）有助于你判断哪些操作可能导致迭代器失效。
六、现代 C++ 的一些辅助工具
C++17 引入了 std::erase_if 等算法式接口，可以在不直接使用迭代器的情况下进行安全的删除操作：
std::vector<int> v = {1, 2, 3, 4, 5};
std::erase_if(v, [](int val) { return val % 2 == 0; });
这种写法不仅更安全，而且代码也更简洁。
写在最后
迭代器是 C++ STL 的核心设计之一，也是构建现代 C++ 编程风格的重要组成部分。
但它不像下标访问那么“直接”，更像是一把双刃剑：用得好，能写出灵活高效的代码；用得不好，可能会引入极难排查的隐患。
不要因为 STL 给你提供了“操作便利”，就忘了它背后的“结构复杂”。
尤其是在容器修改过程中，对迭代器的使用一定要足够小心。