异步方法中捕获循环变量会导致所有任务共享最后一次迭代的值，因闭包捕获的是变量引用而非当时值；C# 5+ 已修复 foreach，但 for 循环需手动用局部变量或本地函数确保捕获值。
异步方法里捕获循环变量会出什么问题
在 for 或 foreach 中直接用变量构建 async Lambda，很可能所有任务都用到最后一次迭代的值。这不是线程安全问题，是闭包捕获变量本身（而非当时值）导致的逻辑错误。
-
for (int i = 0; i console.WriteLine(i)));→ 输出全是3 - 即使改成
async方法或Task.Run(async () => { ... })，只要 Lambda 捕获的是循环变量，问题依旧 - C# 5+ 已修复
foreach变量捕获行为（每个迭代有独立副本），但for仍需手动处理
如何安全地在 async Lambda 中使用循环索引
核心原则：让闭包捕获「值」，而不是「变量引用」。最直接的方式是在循环体内声明新局部变量。
for (int i = 0; i < 3; i++) { int localI = i; // 关键：创建值拷贝 tasks.Add(Task.Run(() => Console.WriteLine(localI))); }- 不要写
var localI = i;然后在 Lambda 里改localI—— 这会破坏不可变性假设 - 如果循环体复杂，可提取为本地函数：
void RunWithIndex(int idx) => Console.WriteLine(idx);，再调用RunWithIndex(i) - 用
Enumerable.Range(0, 3).Select(i => Task.Run(() => Console.WriteLine(i)))也安全，因为select的参数i是每次调用传入的值
await 表达式内部的闭包变量生命周期
Lambda 本身不 await，但被 await 的异步操作（比如 HttpClient.GetAsync）若依赖外部变量，这些变量必须在 await 完成前保持有效。常见于局部变量提前释放或对象被 GC。
- 避免在 Lambda 中捕获
using块内的资源（如var stream = new MemoryStream()），除非确保它活过整个异步链 - 若 Lambda 捕获了类字段或
this，要注意该实例是否可能在 await 期间被销毁（例如 ASP.net Core 中的 Controller 实例生命周期） - 调试时注意：VS 调试器显示的「当前变量值」可能不是 await 恢复时的真实值，建议加日志打点确认实际执行时刻的值
用 ReSharper 或 C# 编译器警告识别风险代码
C# 编译器从 7.0 开始对明显危险的循环变量捕获给出 CS1998（未 await 的 async 方法）等间接提示，但不会直接报闭包问题。ReSharper 更敏感：
- 警告
access to modified closure出现在 Lambda 内读取、且循环外有写入的变量上 - ReSharper 默认高亮
for (int i...) { Action a = () => i; i++; }类型代码 - 启用
dotnet_diagnostic.CA2007.severity = warning（避免直接 await Task）虽不针对闭包，但能暴露异步流中变量作用域失控的苗头
真正容易被忽略的是：闭包变量在 try/catch 或 using 块中被修改，而 Lambda 在 finally 或异步回调中执行 —— 此时变量状态完全不可预测。