范围for循环中调用push_back会触发未定义行为，因容器扩容导致迭代器失效，进而引发崩溃或数据错乱；std::vector等连续容器最危险，std::list虽不使迭代器失效但会破坏end()语义致死循环。
在范围for循环中调用 push_back 会触发未定义行为
直接在 for (auto& x : container) 循环体内对 container 调用 push_back、emplace_back 或任何可能引起重新分配的操作，会导致迭代器失效——而范围for底层依赖 begin()/end() 迭代器。一旦容器扩容（如 std::vector 容量不足），原有迭代器全部失效，后续解引用 *__it 就是未定义行为，常见表现是程序崩溃、数据错乱或静默错误。
-
std::vector、std::string等连续存储容器最危险：一次push_back可能导致整个迭代器范围失效 -
std::list、std::forward_list插入不使其他迭代器失效，但范围for仍不安全——因为end()迭代器语义被破坏，循环可能永远无法终止（新元素被不断纳入遍历） - 即使没崩溃，逻辑也大概率出错：你本想遍历“原始快照”，实际却在边遍历边延长序列
insert 或 erase 在循环中同样不可行
范围for的结构隐含了“先求 begin/end，再逐个推进”的顺序，它不支持中途修改容器边界。哪怕只是 container.insert(container.end(), val)，只要该操作改变了 end() 所指位置（或使已有迭代器失效），循环就失去控制依据。
-
erase更危险：删掉当前元素后，++__it会跳过下一个元素，或解引用已销毁节点 - 没有“安全擦除当前元素”的写法——
erase返回新迭代器，但范围for不提供访问它的入口 - 试图用
continue躲避无效：循环机制本身已崩坏，continue只是继续执行下一次无效的++__it
真需要边遍历边增删？换传统 for + 迭代器
唯一可控的方式是显式管理迭代器，并根据操作结果手动调整位置。例如安全地删除满足条件的元素：
for (auto it = vec.begin(); it != vec.end(); ) {
if (should_remove(*it)) {
it = vec.erase(it); // erase 返回下一个有效迭代器
} else {
++it;
}
}
- 增删逻辑必须与迭代器推进耦合，不能分离
- 避免用
vec.size()控制循环：增删后大小变化，索引容易越界或遗漏 - 若需批量追加，先收集待加元素到临时容器，循环结束后统一
insert或splice
C++20 的 init-statement 不解决这个问题
有人误以为 C++20 的 for (std::vector v{...}; auto& x : v) 能隔离风险——其实不能。这个语法只控制 v 的作用域，不改变范围for的遍历契约。只要你在循环体里对 v 做 push_back，照样触发迭代器失效。初始化位置和容器生命周期无关遍历安全性。
真正容易被忽略的是：范围for的简洁性来自“只读假设”。一旦打破这个假设，就必须放弃语法糖，回到迭代器层面直面内存模型和容器契约。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
