迭代器失效必然发生于容器修改时，vector等连续存储容器在push_back扩容、erase、clear等操作后所有旧迭代器立即失效；应优先用索引或范围for循环，修改前完成读取，必要时预分配内存。
迭代器失效不是“会不会发生”的问题，而是“什么时候、为什么、怎么暴露”的问题。直接结论：只要容器被修改（尤其是 vector、string、deque），且你持有旧迭代器并继续解引用或递增，就极大概率触发未定义行为——崩溃、数据错乱、静默错误都有可能，别等它出事才查。
怎么快速确认是不是迭代器失效导致的崩溃
最典型的现场信号是：程序在 *it、it++ 或 it != container.end() 这类看似安全的操作上突然 segfault 或断言失败。尤其注意以下组合：
- 用
gdb查看崩溃点，如果栈帧停在std::vector::operator[]、__gnu_cxx::__normal_iterator::operator*等内部函数里，且it的地址明显不在当前container.data()范围内，基本可锁定 - 在
libstdc++（GCC）下开启调试模式：-D_GLIBCXX_DEBUG编译，它会在运行时主动检查迭代器越界/失效，并抛出std::out_of_range或直接 abort，比静默崩溃好定位得多 - VS（MSVC）默认就带强迭代器检查，崩溃时会明确提示 “vector iterator not dereferencable” 或类似断言信息
vector 中哪些操作一定让 it 失效
不是“可能”，而是有明确规则。只要发生以下任一情况，所有已存在的 iterator、const_iterator、pointer、reference 都不可再用：
-
push_back()或insert()触发扩容（即size() == capacity()时插入）→ 所有迭代器完全失效 -
erase(it)→ 被删位置及之后的所有迭代器失效（不只是it本身） -
clear()、resize(0)、assign()→ 所有迭代器失效 -
reserve(n)且n > capacity()→ 所有迭代器失效（即使没动元素）
注意：pop_back() 不扩容也不移动前面元素，只让 end() 失效；erase(it) 返回新有效迭代器，但你必须用它覆盖旧变量，否则继续用原 it 就是踩坑。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
为什么 list 和 map 没这个问题，但别无脑套用
std::list 是双向链表，插入/删除只改指针，节点内存地址不变，所以除被删节点本身的迭代器外，其余全部保持有效；std::map/std::set 基于红黑树，插入不破坏现有节点，删除只使被删节点迭代器失效。
- 但这不意味着它们更“安全”——比如你用
list存大量小对象，缓存局部性差，性能可能比vector差一个数量级 - 更关键的是：算法逻辑若依赖连续内存（如
std::sort、std::binary_search）就不能用list迭代器直接传入 - 用
map替换vector只为躲迭代器失效，往往掩盖了设计问题：你真需要按 key 查找，还是只是想避免重分配？
真正靠谱的处理方式不是“修 bug”，而是“不给失效机会”
排查是救火，预防才是工程常态。核心就三条：
- **少存迭代器，多存索引或值**：对
vector，优先用size_t i下标访问；要遍历时用基于范围的for (auto& x : vec)，天然避开迭代器生命周期管理 - **修改容器前，先完成所有读取**：比如要过滤并修改
vec，别边遍历边erase，先用std::remove_if+erase两步走，或收集待删索引再批量删 - **扩容可控化**：确定容量上限？提前
vec.reserve(N)；不确定但频繁插入？考虑std::deque（虽仍部分失效，但不全崩）或分块vector<vector>></vector>
最难缠的其实是视图（std::views::filter 等）+ 底层容器组合场景——这时失效不是容器自己改的，而是视图内部状态和原始数据耦合太深。这种地方，别省那几行代码，老老实实拷贝一份快照再处理。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
