闭包捕获的是变量地址而非值快照，循环中直接捕获循环变量会导致所有闭包共享同一内存位置，循环结束后读取的均为终值；正确做法是在循环体内声明局部副本（如int local = i）再捕获，确保每个闭包绑定独立变量实例。
循环体内频繁创建栈帧并捕获局部变量，本身不会“频繁创建栈帧”——栈帧是每次函数调用时才生成的，而循环体在同一个函数内反复执行，共用同一个栈帧。真正的问题在于：**循环中定义的闭包（如Lambda、匿名函数）捕获了循环变量，导致多个闭包共享同一变量地址，引发运行时逻辑错误**。这是C#和部分C++/JS场景下被反复验证的经典陷阱，不是编译错误，但编译器行为会放大其危害。
闭包捕获的是变量地址，不是值快照
在for或while循环中直接捕获循环变量（如i），所有闭包实际引用的是栈上同一个内存位置。循环结束时该变量已定格为终值，后续调用全部读取这个终值。
- C# 5之前，
foreach变量也存在同样问题；C# 5+已修复，每次迭代生成独立变量实例 - C++11 Lambda若以引用方式捕获
[&i]，行为与C#完全一致 - JavaScript中
var声明的循环变量在闭包中同样被共享（ES6用let可解决）
编译器不报错，但生成的IL/ASM暴露本质
编译器不会拒绝这类代码，因为它语法合法。但反编译可见：C#会将捕获的变量提升为匿名类字段，所有Lambda共享同一个实例字段；C++则把引用捕获转为对栈地址的直接访问。
- C#生成的
c__DisplayClass0_0类中，i成为公共字段，多个委托实例都读写它 - Clang/GCC对
[&i]Lambda不做额外栈保护，越界修改可能破坏相邻局部变量（如前文数组越界改写i导致死循环） - 启用
/clr或调试模式时，JIT或编译器可能插入调试符号，但不改变语义
多线程环境下风险指数级放大
当闭包被用于新线程（如Task.Run或std::thread），变量竞争不再只是逻辑错误，而是未定义行为（UB）。
- 主线程循环尚未结束，子线程已开始读取
i——此时值不确定 - 多个线程同时写入同一栈地址（如
i++），无原子性保障，结果不可预测 - 栈帧随主线程函数返回而销毁，子线程若延迟执行，将访问已释放栈内存，触发SIGSEGV
安全写法：显式创建独立作用域副本
核心原则是让每个闭包绑定一个独占的、生命周期可控的变量实例。
- C#：在循环体内声明
int local = i;，再捕获local - C++：用
[i] { ... }值捕获（推荐），或[i_copy = i] { ... }（C++14起） - 通用技巧：用立即调用的lambda包装，传入当前循环变量作为参数
