迭代器失效后不可判断有效性，因C++标准禁止对失效迭代器执行任何操作（包括比较），否则触发未定义行为；vector/deque应避免保存迭代器，改用索引。
迭代器是否有效，不能靠“判断”——C++ 标准明确禁止对失效迭代器执行任何解引用或比较操作，一旦失效，其值是未定义的，it == container.end() 这类检查在失效后也毫无意义，甚至会触发未定义行为（UB）。
为什么不能用 if 判断迭代器是否还有效
失效的迭代器不是“指向空”或“等于 nullptr”，而是进入不可预测状态。常见误解是写类似 if (it != container.end()) 来“防护”，但若 it 已因 erase、push_back、resize 等操作失效，该比较本身就会导致 UB（尤其在 libstdc++ 的 debug 模式下会直接 abort）。
- 所有标准容器（
vector、deque、list、map等）都不提供is_valid()成员函数 -
std::iterator_traits也不提供运行时有效性检测接口 - 调试器中看到
it._M_current为nullptr或野地址，只是实现细节，不可依赖
vector 和 deque 迭代器失效的典型场景与规避方式
vector 和 deque 的迭代器在内存重分配时极易失效，核心原则是：**不保存可能被 invalidate 的迭代器，改用索引或重新获取**。
-
push_back/emplace_back：仅当触发 reallocation 时，所有迭代器失效 → 若需保留位置，优先用size_t index = it - v.begin()，操作后再用v.begin() + index恢复（确保index ） -
erase(it)：返回下一个有效迭代器 → 必须用it = v.erase(it)，而非v.erase(it); ++it -
insert在中间：所有迭代器可能失效 → 避免长期持有，或改用vector::data()+ 索引计算
std::vector<int> v = {1, 2, 3, 4};
auto it = v.begin() + 2; // 指向 3
v.push_back(5); // 可能失效！此时不能再用 it
// 正确做法：用索引
size_t pos = it - v.begin();
v.push_back(5);
if (pos < v.size()) {
int val = v[pos]; // 安全访问
}list、map、set 等节点式容器的相对安全性与陷阱
list、map、set、unordered_map（仅桶不重哈希时）的迭代器在插入时不失效，但删除当前迭代器所指节点时，该迭代器立即失效 —— 这是最常踩的坑。
立即学习“C++免费学习笔记（深入）”；
-
erase(it)后，it失效，但erase返回的是新有效迭代器（C++11 起）→ 必须赋值：it = c.erase(it) - 遍历时删除多个元素，不能用
for (++it)结构，而要用while+erase返回值 -
unordered_map::rehash可能导致所有迭代器失效（即使没删元素），但标准不强制要求立刻失效；实际中应避免在循环中触发扩容（如预设足够reserve）
std::map<int, std::string> m = {{1,"a"}, {2,"b"}, {3,"c"}};
for (auto it = m.begin(); it != m.end(); ) {
if (it->first % 2 == 0) {
it = m.erase(it); // 关键：接收返回值
} else {
++it;
}
}通用预防策略：从设计上消除迭代器生命周期管理负担
最可靠的方式，是让迭代器“活不过单次表达式”——即不跨函数边界、不存入成员变量、不在循环条件中长期持有。
- 用基于范围的 for 循环（
for (const auto& x : container)）处理只读遍历，完全避开迭代器变量 - 修改容器时，优先用算法替代手写循环：
std::remove_if+erase（erase–remove 惯用法） - 若必须缓存位置，用
container.size_type索引代替迭代器（对list不适用，但可改用std::next+std::distance模拟） - 启用编译器 debug 模式（如 GCC 的
-D_GLIBCXX_DEBUG）可捕获多数迭代器误用，在开发阶段暴露问题
迭代器失效不是“偶尔出错”，而是未定义行为的入口。真正安全的做法不是事后检测，而是在逻辑层面切断失效路径——把“我怎么知道它还有效”这个问题，变成“我根本不会让它失效”。
