C++标准未提供检测迭代器失效的接口，所有检测手段均不可靠且可能导致未定义行为；失效本质是底层状态指向非法内存，运行时无元信息可查，安全做法是编码阶段规避而非运行时判断。
不能直接判断迭代器是否失效 —— C++ 标准没有提供任何 is_valid() 或类似接口，所有试图“检测”失效迭代器的手段都是不可靠的、非标准的，甚至本身就是未定义行为的源头。
为什么无法安全判断迭代器是否失效
迭代器失效的本质是底层指针/状态指向了已释放内存、已移动元素或根本不存在的位置。这种状态在语言层面不暴露给用户，运行时也无元信息可查。
- 对失效迭代器调用
operator==（比如和end()比较）可能崩溃，也可能偶然返回true或false，结果不可预测 - 解引用
*it、自增++it、甚至仅读取其内部字段（如某些 debug 版本的_M_current）都属于未定义行为 - VS 的 debug mode 会插入检查并抛异常，但这只是调试辅助，不是可移植逻辑；GCC/Clang 默认完全不检查
vector 插入后原迭代器是否还能用？看扩容与否
vector 的迭代器失效高度依赖容量变化：只要发生 realloc（即 size() > capacity() 触发扩容），所有现存迭代器、指针、引用全部失效；否则只影响插入点及之后位置。
-
push_back()后，原begin()迭代器是否有效？→ 查v.capacity() >= v.size()之前值；但你无法回溯这个值，所以不能靠判断，只能靠预防 -
reserve(n)能避免扩容类失效，但不能防止插入点后迭代器失效（例如insert(it, x)会使it及之后所有迭代器失效） - 别试图用
it - v.begin()算偏移再重算 —— 如果it已失效，减法本身已是 UB
list/map 等容器删除时最易踩的坑：erase 后继续用 it
节点式容器（list、map、set、unordered_map）的迭代器只在指向被删节点时失效，但很多人忽略 erase() 返回值的正确使用。
立即学习“C++免费学习笔记（深入）”；
-
it = c.erase(it)是唯一安全方式；写成c.erase(it); ++it;必然 UB，因为it已失效，++it不合法 - 遍历中条件删除必须用 while + 手动控制迭代器前进：
for (auto it = c.begin(); it != c.end(); ) { if (...) it = c.erase(it); else ++it; } -
end()迭代器本身也受修改影响：某些操作（如vector::erase最后一个元素）会让旧end()失效，不应长期缓存
真正可行的防御策略：不依赖判断，而靠编码惯式
与其纠结“怎么判断”，不如从设计上绕开问题。失效不是 bug，而是容器语义的一部分；应对它的核心是：操作后立即更新，或改用更鲁棒的访问方式。
- 修改容器前，若需后续访问某元素，优先保存索引（
size_t pos = it - c.begin()）而非迭代器；对list/map则保存 key 或指针 - 批量删除统一用
remove_if + erase惯式（vector）或erase返回值循环（所有容器） - 调试阶段启用 STL debug mode（如 GCC 的
-D_GLIBCXX_DEBUG，MSVC 的_ITERATOR_DEBUG_LEVEL=2），但它只报错，不帮你“判断” - 对性能敏感场景，
vector预留空间 + 避免中间插入；list改用splice替代反复erase/insert
迭代器失效不是运行时可诊断的问题，而是编译期+设计期就该规避的契约约束。最危险的代码，往往是在“以为它还有效”的前提下，悄悄读写了野地址。
