lambda捕获的是循环变量引用而非值快照，导致for中所有委托执行时输出同一终值；foreach在c#5.0+安全因每次迭代创建独立变量实例，但仍存在闭包开销与生命周期风险。
所有 Lambda 共享同一个循环变量，不是“值快照”，而是“变量引用”——这是最常踩、也最容易被忽略的根本原因。
for 循环中直接捕获 i 为什么总是输出最后一个值？
因为 C# 的 for 循环只声明一个 i 变量，每次迭代只是修改它的值。Lambda 捕获的是这个变量本身，不是某次迭代时的值。等所有委托真正执行时，i 早已变成循环终止值（比如 5 或 buttons.Length）。
常见错误现象：
- 注册多个 UI 点击事件，结果全触发同一个索引
- 延迟执行的定时任务，全部打印出相同的计数器终值
- 在
Task.Run中调用，日志里全是重复数字
实操建议：
- 必须在循环体内显式创建局部副本：
int localI = i;，再捕获localI - 不要依赖 IDE 自动提示或“看起来没问题”的写法，
for的行为从 C# 1.0 到 2026 年都没变 - Unity 开发中尤其危险：高频调用 + GC Alloc，可能引发卡顿
foreach 在 C# 5.0+ 是安全的，但别误以为它“没闭包”
C# 5.0 起，foreach 每次迭代都会生成独立的循环变量实例，所以 foreach (var item in list) actions.Add(() => Console.WriteLine(item)); 能正确输出不同值。但这不等于没有闭包——它仍有闭包类，只是每个委托捕获的是各自独立的变量。
容易踩的坑：
- 误把
foreach的安全性套用到for上，混用导致逻辑错乱 - 在
foreach中修改item本身（如item.Id = 999），后续捕获仍能看到修改，因为是引用类型共享 - 跨方法传入
foreach变量并捕获，实际捕获的是该方法作用域内的变量，不是原始集合项
性能影响：即使安全，每个 foreach 迭代仍会分配一个闭包对象（堆上），大量迭代 + 高频触发场景需评估 GC 压力。
闭包变量生命周期比你想象的长得多
只要还有委托（比如事件处理器、缓存的 Func、静态字段持有的 Action）引用该变量，编译器生成的闭包类就不会被 GC 回收——哪怕外层方法早已返回。
典型风险场景：
- 给静态事件（如
Application.quitting）添加 Lambda，意外捕获了大对象（byte[]、List<t></t>） - 在工厂方法中返回捕获了
this的 Lambda，导致整个实例无法释放 - 用
async方法捕获局部变量，await 后续仍持有闭包，延长栈变量生命周期
实操建议：
- 检查闭包是否真的需要捕获大对象；优先捕获 ID 或关键字段，而非整个实体
- 注册事件后记得手动移除，尤其使用 Lambda 时：
handler = () => ...; obj.Event += handler;→obj.Event -= handler; - 用 Visual Studio 的内存快照工具或 dotMemory 查看闭包类实例数量，确认是否异常堆积
Lambda 不支持默认参数，但可以用闭包“模拟”
(x, y = 1) => x + y 是非法语法，编译直接报错。C# 的 Lambda 必须严格匹配委托签名，不参与方法重载或可选参数解析。
可行替代方式：
- 用外部变量捕获默认值：
int defaultY = 1; Func<int int> add = x => x + defaultY;</int> - 封装为具名方法，再由 Lambda 调用：
int Add(int x, int y = 1) => x + y; Func<int int> add = x => Add(x);</int> - 避免在热路径（如
Update、OnGUI）中反复创建新闭包，复用已定义的委托实例
注意：defaultY 被捕获后，若外部修改它，所有已创建的 Lambda 都会看到新值——这不是 bug，是闭包本意，但容易被当成“状态泄漏”。
真正难处理的从来不是语法，而是变量捕获后谁在什么时候还拿着它；多数内存泄漏和逻辑错乱，都藏在“我以为它早该没了”的那个瞬间。
