我自己也一直在想，这就是为什么我总是带着这个:

public static void ForEach<T>(this IEnumerable<T> col, Action<T> action)
{
    if (action == null)
    {
        throw new ArgumentNullException("action");
    }
    foreach (var item in col)
    {
        action(item);
    }
}

不错的扩展方法。

我想对Aku的回答进行进一步阐述。

如果你想调用一个方法的唯一目的是它的副作用，而不是首先迭代整个枚举对象，你可以使用这个:

private static IEnumerable<T> ForEach<T>(IEnumerable<T> xs, Action<T> f) {
    foreach (var x in xs) {
        f(x); yield return x;
    }
}

大多数LINQ扩展方法都返回结果。ForEach不符合这个模式，因为它什么也不返回。

ForEach方法在LINQ之前添加。如果您添加ForEach扩展，由于扩展方法的约束，它将永远不会被用于List实例。我认为没有添加的原因是为了不干扰现有的。

但是，如果您真的错过了这个漂亮的小函数，您可以推出自己的版本

public static void ForEach<T>(
    this IEnumerable<T> source,
    Action<T> action)
{
    foreach (T element in source) 
        action(element);
}

一种解决方法是编写. tolist()。ForEach(x =>…)

pros

易于理解——读者只需要知道c#附带了什么，而不需要知道任何额外的扩展方法。

语法干扰非常温和(只添加了一点无关的代码)。

通常不需要额外的内存，因为本机. foreach()必须实现整个集合。

cons

操作顺序并不理想。我宁愿实现一个元素，然后付诸行动，然后重复。这段代码首先实现所有元素，然后依次对它们进行操作。

如果意识到列表抛出异常，则永远无法对单个元素进行操作。

如果枚举数是无限的(就像自然数一样)，那么你就不走运了。

这里的讨论给出了答案:

实际上，我所看到的具体讨论确实取决于功能的纯洁性。在一个表达式中，经常会有关于没有副作用的假设。使用ForEach是特别吸引副作用，而不仅仅是忍受它们。——基思·法默(合伙人)

基本上，这个决定是为了保持扩展方法在功能上的“纯粹”。ForEach在使用Enumerable扩展方法时会产生副作用，这不是目的。