企业官网建设流程全解析

如果你写过一段看起来很正常的 C#：一个for循环，往List<Action>里塞几个 lambda，最后再统一执行，你应该还记得那种被结果震到的感觉——不是0 1 2 3 4，而是连续五个5。网上聊得最多的叫法是“foreach 循环的坑”，但我一直觉得它更准确的名字是“闭包捕获循环变量”的坑，foreach 只是最经典的案发现场而已。这篇文章想把这件事从头到尾讲清楚：闭包到底捕获了什么，C# 5 改掉了哪个行为，for 循环为什么到今天还保留着同样的问题，以及我在 LINQ、异步、并行业务里踩过的同款坑。无论你是刚学委托的小白，还是写了很多年代码、时不时要在代码评审里抓这种问题的老手，这篇都应该对你有用。

1. 先复现一次“灵异事件”：十行代码输出五个 5

1.1 一段几乎人人都写过的代码

先看最常被拿来演示的版本，用的是for：

var actions = new List<Action>(); for (int i = 0; i < 5; i++) { actions.Add(() => Console.WriteLine(i)); } foreach (var action in actions) { action(); }

直觉告诉我，这段代码应该输出0 1 2 3 4。但实际运行结果往往是这样：

5 5 5 5 5

五个5。

如果换成foreach：

var actions = new List<Action>(); foreach (int i in Enumerable.Range(0, 5)) { actions.Add(() => Console.WriteLine(i)); } foreach (var action in actions) { action(); }

在今天的 C# 编译器下运行，你会看到0 1 2 3 4。但在 C# 5 之前的老编译器下，结果依然可能是5 5 5 5 5。所以很多老博客、旧面试题都把这件事记成了“foreach 的坑”。其实 foreach 只是被拿来背锅的，真正的原因是闭包。

1.2 为什么输出会是这样

闭包本质上是一种“变量捕获”机制：方法里的 lambda、匿名方法，甚至局部函数，都可以引用外面作用域的局部变量。问题在于，被捕获的并不是那一刻变量的“值”，而是变量本身，或者说，是编译器为这个变量准备的“存储位置”。

可以这样想：你把一把储物柜钥匙交给了五个朋友，锁柜门之前你反复修改柜子里的东西。柜门锁上后，五个朋友各自打开同一个柜子，看到的当然是最后一次放进去的内容。for循环里的i就是那个储物柜，五个 lambda 拿到的不是五份i的复印件，而是指向同一个i的钥匙。

所以真正发生的是：循环结束后，i已经变成5。你调用五个委托时，每个委托都去读同一个变量的当前值，自然都读到5。

1.3 闭包在这里究竟闭住了什么

不少初学者容易误解成“闭包会把局部变量的值快照下来”。不是的。闭包更像是在局部变量原本的作用域结束后，仍然保留着对它的访问权。为了实现这一点，编译器会做变量提升，把局部变量变成一个更长久存在的对象字段。这也是后面所有坑的根源。

代码里写() => Console.WriteLine(i)，并不是把i的值编译进 lambda，而是让 lambda 持有一个可以随时读取i的引用。你可以在闭包里看到外部变量的最新变化，而不是捕获当时的副本。理解这一点，许多看似“灵异”的行为就说得通了。

2. 编译器与闭包实现：变量提升才是根源

2.1 编译器悄悄改写了你的局部变量

为了让你理解闭包，最好看一眼编译器在背后做了什么。下面这段代码：

int i = 42; Action print = () => Console.WriteLine(i);

在概念上会被改写成类似这样：

internal sealed class DisplayClass { public int i; public void Print() { Console.WriteLine(i); } }

然后原本的int i = 42;变成了：

var closure = new DisplayClass(); closure.i = 42; Action print = closure.Print;

也就是说，编译器把局部变量i从“栈上的一个变量”提升成了一个“闭包对象里的字段”。lambda 不再和方法局部变量直接打交道，而是通过这个对象去访问i。只要闭包对象还活着，i就会一直活着。

这也是为什么闭包里的变量生命周期会被延长：不是 C# 做了一些魔法，而是编译器把它挪到了一个堆上的对象里。

实际调试时，你很难直接看到这个DisplayClass，它通常叫类似<>c__DisplayClass0_0的名字。看到这类名字，基本就能断定有闭包生成了。

2.2 foreach 变量从“同一个”到“每一次迭代一个”

回到循环场景。用for改写编译后的逻辑，大致是这样的：

var closure = new DisplayClass(); for (closure.i = 0; closure.i < 5; closure.i++) { actions.Add(closure.Print); }

这里只创建了一个闭包对象，所有委托都指向同一个closure.Print，自然都读到同一个closure.i。

而 C# 5 之后，foreach的编译结果在概念上变成了每次迭代创建一个新的闭包对象：

foreach (int item in Enumerable.Range(0, 5)) { var closure = new DisplayClass(); closure.item = item; actions.Add(closure.Print); }

每次迭代都有自己独立的closure，每个closure.item都保存着当次迭代的值。所以后来执行委托时，会分别输出0 1 2 3 4。修复的实质不是编译器“聪明”了，而是规范规定了 foreach 的迭代变量在语义上每次迭代都是新变量。

2.3 为什么局部复制这招百试百灵

网上流传的经典修复方法，是在循环体内先复制一份局部变量：

for (int i = 0; i < 5; i++) { var current = i; actions.Add(() => Console.WriteLine(current)); }

这段代码无论在新老编译器上结果都是0 1 2 3 4。原因很简单：current声明在循环体内部，每一次迭代都产生一个新的局部变量。编译器为闭包提升变量时，每个迭代的闭包对象里都有一份独立的current。

在 C# 5 之前，人们写 foreach 时也靠这个技巧避坑：

foreach (var item in items) { var copy = item; actions.Add(() => Use(copy)); }

即使 foreach 已经被新编译器修复，我仍然建议你在某些敏感场景保留这个习惯。因为它不仅兼容老代码库，更能提醒后面读代码的人：这里存在闭包捕获，请小心。

3. foreach 已修复，for 还是老样子：别再记反了

3.1 C# 5 那一次规范变化，具体改了什么

C# 5 的规范做了一个非常有针对性的调整：foreach的迭代变量不再被认为是循环外部的同一个变量，而是每次迭代都有一个新的变量。这个修改直接影响闭包捕获的行为。

C# 5 之前，可以理解为编译器把 foreach 展开成类似这样：

IEnumerator<int> enumerator = source.GetEnumerator(); int item; while (enumerator.MoveNext()) { item = enumerator.Current; actions.Add(() => Use(item)); }

这里的item是循环外声明的同一个变量，所以闭包捕获的自然也是同一个。

C# 5 之后，item在语义上被移到了循环体内部：

IEnumerator<int> enumerator = source.GetEnumerator(); while (enumerator.MoveNext()) { int item = enumerator.Current; actions.Add(() => Use(item)); }

每次迭代重新声明item，闭包捕获的就不再是同一个变量了。

这也是为什么今天的 C# 里，直接写foreach + lambda通常不会踩坑。但这份安全感很容易让人忘记另一个事实：for循环从没被修过。

3.2 for 循环为什么一直没改

for循环的结构和foreach不一样。for (int i = 0; i < 5; i++)里的i承担了三种职责：初始化、条件判断、每次迭代后的递增。这三个动作都依赖同一个变量在循环过程中持续存在。

如果照搬 foreach 的修法，把i改成每次迭代都是新变量，那么i++到底该作用于哪个i？条件判断i < 5读的又是哪一个i？语义会变得非常混乱。所以 C# 选择保留for循环的旧语义：整个循环只有一个i。

这就导致了一个很微妙的现状：老一辈踩的 foreach 坑，现在基本消失了；但同一套闭包捕获逻辑，放到for循环里，还是百分之百复现。很多新人都把注意力放在 foreach 上，反而对for里写 lambda 毫无戒备。

3.3 一张表看清各种写法的行为

这段对比建议你存下来。以后评审代码时，看到for循环里有 lambda，先默认它是危险的；看到foreach里有 lambda，也要先确认项目用的语言版本，再决定要不要“放行”。局部函数和匿名方法也适用同样的规则，它们本质上都是闭包。

4. 当闭包撞上延迟执行：LINQ 查询里的连环坑

4.1 延迟执行把“取值时刻”推后了

很多人以为只有把委托存到List里再统一调用才会出问题。其实更隐蔽的是 LINQ 的延迟执行。LINQ 查询本身不会立刻遍历数据，它只是把一堆操作“攒起来”。真正开始计算，是当你调用ToList()、ToArray()，或者用foreach去枚举它的时候。

这意味着如果 LINQ 查询里捕获了循环变量，取值时机被推到了“查询真正枚举时”，而不是“创建查询时”。这时候循环变量可能早就变成了最终值，然后所有查询片段都在用这个最终值计算。

4.2 用 for 拼出来的 LINQ 查询，怎么修

看一个典型场景：你想把同一个数据源按不同偏移量拼成一个查询序列。

var source = Enumerable.Range(1, 3).Select(x => x * 10); var query = Enumerable.Empty<int>(); for (int i = 0; i < 3; i++) { query = query.Concat(source.Select(x => x + i)); } Console.WriteLine(string.Join(",", query));

期望也许是这样三组：10 20 30 11 21 31 12 22 32。

实际输出却会是：

13,23,33,13,23,33,13,23,33

原因很简单：query.Concat(source.Select(x => x + i))里的i被闭包捕获。真正枚举query时，i 已经是3，于是三组查询全部按x + 3计算。

修复方法和之前一模一样，循环体内先复制一份：

for (int i = 0; i < 3; i++) { var offset = i; query = query.Concat(source.Select(x => x + offset)); }

这时每次Concat捕获的都是不同的offset，最终枚举结果才符合预期。

4.3 迭代变量以外的坑：外部可变状态

闭包捕获的不仅是循环变量，任何外部变量被捕获后，闭包看到的是它的“当前状态”，不是“捕获那一刻的值”。

int seed = 100; Func<int> getValue = () => seed + 1; seed = 200; Console.WriteLine(getValue()); // 201

这就是许多线上 bug 的另一个来源：你以为 lambda 只是记录了一个公式，实际上它时刻在读取外部状态。配合缓存、静态字段、实例字段，行为会变得更难预测。

我在代码评审里经常说一句话：如果一个 lambda 要长时间存活，或者会在很晚之后才执行，那它对外部变量的每一次读取，都要问一句“它到时候会读到什么”。不要默认“现在值是什么，将来就是什么”。

5. 异步与并行场景：闭包陷阱被放大后更难排查

5.1 Task.Run 与 async lambda 的经典现场

闭包陷阱在异步场景里最让人头疼，因为出现顺序、耗时都会影响你能不能稳定复现。

看这段代码：

var tasks = new List<Task>(); for (int i = 0; i < 5; i++) { tasks.Add(Task.Run(async () => { await Task.Delay(100); Console.WriteLine(i); })); } await Task.WhenAll(tasks);

Task.Run接收的 async lambda 捕获了同一个i。循环结束后，i变成5，五个任务在延迟后读取的往往是同一个最终值。你可能会看到一串5，也可能因为任务调度时机不同，看到个别0~4的值混在里面。这种不确定性最讨厌：它时好时坏，很容易被当成“偶发问题”放过。

想让行为稳定复现，最简单的方法是别在异步任务创建阶段依赖循环变量，而是先复制一份局部快照：

for (int i = 0; i < 5; i++) { var current = i; tasks.Add(Task.Run(async () => { await Task.Delay(100); Console.WriteLine(current); })); }

5.2 为什么 Parallel.For 反而安全

提到并行，很多人容易条件反射地紧张。但实际上Parallel.For(0, 5, i => ...)是相对安全的，原因很简单：Parallel.For回调里的i是方法参数，每次迭代都由框架作为参数传进来，并不是闭包捕获外部循环变量。

真正危险的是你在for循环里手动捕获循环变量，然后丢给并行任务或线程池：

for (int i = 0; i < 5; i++) { var current = i; Parallel.Invoke(() => DoWork(current)); }

如果去掉var current = i;，让DoWork(i)直接捕获取值，又会回到共享变量的老问题。结论是：闭包不关心你是串行还是并行，它只关心“被捕获的变量是否共享”。

5.3 写代码时的三条自查清单

在异步和并行场景里，我慢慢形成了一套自查习惯。写代码时只要循环体里出现了 lambda、匿名方法或局部函数，就问三个问题：

1. 这个 lambda 里有没有引用循环变量？
2. 这个 lambda 是立刻执行，还是会被存起来、放进 LINQ、交给异步任务，之后才执行？
3. 如果之后才执行，循环变量在那时还是我想要的值吗？

如果第一问是“有”，第二问是“之后才执行”，那基本就要踩坑。不要心存侥幸，直接复制一份局部变量再捕获。

常见的反例还包括：把循环变量写进async void事件处理、把委托塞进缓存队列、把Expression表达式树保存到配置文件等。表面形式五花八门，底层机制完全一样。

6. 我现在的代码习惯：评审和自测时怎么一眼识破

6.1 看到这个模式就报警

现在我评审代码时，几乎养成了肌肉记忆：只要看到for+ 循环体内创建委托，就会立刻检查委托体里有没有引用i。如果有，我的第一反应不是去讨论“这次碰巧对不对”，而是直接要求改成局部变量快照。

对foreach，我会多问一句项目使用的语言版本和编译器。如果是一个维护了很久的老项目，或者需要兼容多版本构建环境，我同样建议复制。虽然新编译器已经修复，但这个额外步骤几乎零成本，还能让意图更清楚：我就是要把当前值变成一份独立副本。

6.2 用最简单的控制台断言验证

与其靠肉眼猜，不如写一个十几行的验证脚本。我经常用这种结构：

var funcs = new List<Func<int>>(); for (int i = 0; i < 3; i++) { funcs.Add(() => i); } var result = string.Join(",", funcs.Select(f => f())); Console.WriteLine(result); // 3,3,3

改成：

var funcs = new List<Func<int>>(); for (int i = 0; i < 3; i++) { var current = i; funcs.Add(() => current); } var result = string.Join(",", funcs.Select(f => f())); Console.WriteLine(result); // 0,1,2

这种小脚本非常适合在代码评审前自己快速验证。你也可以在调试器里给委托内部设断点，观察闭包变量是否在每次调用时都显示同一个值。一旦发现所有断点命中的值相同，基本就能确定问题出在共享变量上。

6.3 给新项目定的小规矩

这些年我在不少项目里推行过一条小规矩：循环体内出现的委托、表达式树或局部函数，除非能证明不涉及外部变量捕获，否则一律不要直接捕获循环变量。尤其是for循环，没有例外。

这不是对开发者的不信任，而是因为代码会演化。今天看起来安全的一行foreach + lambda，明天可能被人改成for，或者被挪进一个延迟执行的查询流程，问题就突然冒出来了。提前做局部快照，相当于从源头切断了整类 bug 的生存空间。

单独看这个坑，好像只是一个语法行为；但它背后反映的其实是“变量生命周期”和“执行时机”这两件大事。理解了闭包捕获的本质，你再回头看那些奇怪的输出、偶发的异步异常、时好时坏的 LINQ 结果，很多都能对得上号。我个人现在的习惯是：宁可多写一行var current = i;，也不愿意在问题发生之后再花半天去查闭包对象里到底存了哪个值。这个习惯救过我很多次，也希望你以后用得上。