vector扩容时迭代器必然失效，因底层连续内存被重新分配，原迭代器指向已释放地址；安全做法是提前reserve()、用erase()返回值更新迭代器，或改用索引遍历。
vector扩容时iterator为什么会突然变野指针
因为std::vector底层是连续内存块，扩容必须申请新内存、拷贝旧数据、释放旧内存。所有指向原内存的iterator（包括begin()、end()、中间任意位置）立刻失效——它们还指着已被free()掉的地址。
这不是“可能失效”，而是“必然失效”。哪怕只插入一个元素触发了capacity()增长，所有旧迭代器全部作废。
- 常见错误现象：
std::vector::insert()或push_back()后继续用原来的it解引用或递增，触发未定义行为（崩溃、乱码、静默错误） - 典型场景：循环中边遍历边
push_back()，或用erase()后没更新迭代器 - 注意：
reserve()不改变size()，但会重新分配内存——同样导致所有迭代器失效
怎么安全地在遍历时修改vector
核心原则：别让迭代器跨过扩容边界。要么提前预留空间，要么用返回值接管新迭代器。
- 如果确定要追加大量元素，先调
reserve()（但注意：这只能防push_back()扩容，不能防insert()在中间插入） - 用
erase()时，必须用它返回的迭代器：it = vec.erase(it)，而不是vec.erase(it); ++it - 需要在遍历中插入？改用索引访问：
for (size_t i = 0; i ，插入不影响索引有效性（但要注意逻辑上是否跳过元素） - 更稳妥的做法：分两步——先收集要插入/删除的位置或值，遍历结束后统一操作
哪些操作一定会导致iterator失效
只要动了底层内存布局，就危险。不是“看起来没变”就安全。
立即学习“C++免费学习笔记（深入）”；
- 明确失效：
push_back()、pop_back()（仅当size()变0且capacity()收缩时）、insert()、erase()、resize()、clear()、swap()（与另一个vector交换后，原迭代器指向对方内存） - 看似安全但实际危险：
operator[]和at()不产生迭代器，所以不涉及失效问题；但如果你拿&vec[0]去算偏移，扩容后这个地址也无效 - 唯一真正安全的操作：
begin()、end()、cbegin()等每次调用都返回新迭代器——所以别缓存，需要时就重新取
调试时怎么快速发现iterator失效
编译器不会报错，运行时行为不可预测。靠肉眼很难定位，得借助工具和习惯。
- 开启标准库调试模式：GCC/Clang加
-D_GLIBCXX_DEBUG，MSVC用_ITERATOR_DEBUG_LEVEL=2，能捕获多数越界和失效访问并直接断言 - 用
valgrind --tool=memcheck或ASan（-fsanitize=address）跑，野指针读写通常会被立即拦截 - 警惕所有“用了很久的迭代器还在循环里用”的代码——尤其在函数内部传入
vector又修改了它，外部迭代器早已不知所踪
最麻烦的不是扩容本身，而是失效发生在深层调用里：你传了个iterator进函数，函数内部push_back()了，回来你还以为它好好的。这种链式失效，连调试器都难一眼揪出。
