C# 5+ foreach循环闭包实现变更及与for差异问询

先看你给出的代码示例：

int[] values = { 7, 9, 13 };
List<Action> f = new List<Action>();
foreach (var value in values)
    f.Add( () => Console.WriteLine("foreach value: " + value));
foreach (var item in f)
    item();

f = new List<Action>();
for (int i = 0; i < values.Length; i++)
    f.Add(() => Console.WriteLine("for value: " + ((i < values.Length)? values[i] : i)));
foreach (var item in f)
    item();

在C# 5及以后，这段代码的输出会是：

foreach value: 7
foreach value: 9
foreach value: 13
for value: 13
for value: 13
for value: 13

而C# 4及更早版本中，foreach的输出会和for循环一致，都是三次13——因为闭包捕获的是同一个value变量。

为何修改foreach的闭包实现？ #

核心原因是旧行为违背了开发者的直觉。绝大多数使用foreach的开发者，预期的是闭包捕获当前迭代的元素值，而非一个在整个循环周期内共享的变量。这种反直觉的行为导致了大量难以排查的bug，尤其是新手在绑定事件、编写异步逻辑时很容易踩坑。

C#语言团队做决策前调研了大量真实代码场景，发现：

• 依赖“捕获当前迭代值”的代码占绝大多数，依赖旧行为（捕获共享变量）的代码极少；
• 修复的收益远大于兼容性风险：依赖旧行为的代码可通过手动在循环内创建变量副本（比如var temp = value; f.Add(() => Console.WriteLine(temp));）保留原有逻辑，绝大多数代码无需修改就能符合预期。

另外从语义上看，foreach的设计目的是遍历集合中的每个独立元素，让闭包捕获每个迭代的独立变量副本，更贴合这个语义本身。

为何仅修改foreach而未修改for循环？ #

主要有三个关键原因：

1. 行为符合直觉与既有实践：for循环的变量（比如示例中的i）是在循环体外声明的，每次迭代只是修改这个变量的值。开发者普遍理解这个变量是共享的，且“在for循环内创建临时变量捕获当前值”已经是广泛传播的解决方案，不存在普遍认知困惑。
2. 兼容性风险极高：大量现有代码依赖for循环变量的共享特性。比如很多代码会在循环结束后使用i的值（比如获取最后一次迭代的索引），或者故意在闭包中捕获变化的i实现特定逻辑。修改for循环的闭包行为会导致这些代码全部失效，代价远大于收益。
3. 语义匹配：for循环的核心语义是使用同一个计数器变量完成遍历，共享变量的行为本身就贴合这个语义。如果修改为每次迭代创建新变量，反而会违背for循环的设计初衷。

内容的提问来源于stack exchange，提问作者Denis Sivtsov