编译器将for(auto x : container)展开为等效迭代器循环：先绑定auto&& __range = container，再调用begin(__range)和end(__range)获取迭代器，最后用__begin != __end控制循环并解引用赋值；begin/end按成员函数、ADL非成员函数、数组重载顺序查找；临时对象生命周期延长至整个for语句结束；循环中修改容器会导致迭代器失效，行为未定义。
编译器会把 for (auto x : container) 展开成迭代器循环
它不是魔法，也不是纯语法糖——编译器在翻译阶段就把它转成等效的传统迭代器代码。具体展开逻辑是：auto&& __range = container → auto __begin = begin(__range) → auto __end = end(__range) → 然后用 __begin != __end 控制循环，每次 *__begin 解引用赋值给 x。
begin() 和 end() 的查找顺序决定能否遍历
编译器按以下优先级找迭代器接口：
- 先查容器自身的成员函数
container.begin()/container.end() - 没找到就查 ADL（Argument-Dependent Lookup）作用域下的非成员
begin(container)/end(container) - 对原生数组，靠重载的非成员
begin(T(&)[N])和end(T(&)[N])支持 - 如果三者都失败，编译报错："
beginwas not declared in this scope"
临时对象生命周期延长只保到整个 for 语句结束
写 for (auto x : std::vector 是合法的，因为编译器会把临时 std::vector 绑定到 auto&& __range，从而延长其生命周期。但注意：
- 这个延长只覆盖整个
for语句块，循环体里存的引用（比如auto& x）一旦离开循环就悬垂 - 若循环体中调用了异步函数并捕获了
&x，运行时大概率崩溃 - 结构化绑定（如
for (const auto& [k, v] : my_map)）同样受此限制
修改容器时迭代器失效，范围 for 不会自动感知
这是最隐蔽也最容易出问题的地方。例如：
std::vector<int> v = {1,2,3,4};
for (auto& x : v) {
if (x == 2) v.push_back(99); // ❌ 触发重新分配，所有迭代器失效
}</int>
这段代码行为未定义——for 循环底层的 __begin 和 __end 在进入循环时就固定了，后续 v.push_back() 可能让它们变成悬垂指针。实际表现可能是跳过元素、重复访问，甚至直接 crash。
真正安全的做法只有两种：
- 先收集要修改的位置（如索引或迭代器），循环结束后再批量操作
- 改用传统
while+erase()模式，且每次erase后用返回值更新迭代器
别指望范围 for 能“智能检测容器变化”——它连容器是不是被别的线程改了都不知道。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
