c#如何遍历List集合_c#遍历List集合的最佳实践与常见坑点

C# List集合遍历：最佳实践与那些你迟早会遇到的“坑”

在C#里，用 foreach 来遍历一个 List，这几乎是条件反射般的操作。它安全、简洁，是大多数场景下的首选。但问题往往就出在这个“大多数”上——一旦你需要边遍历边修改集合，比如删除某个元素，熟悉的 InvalidOperationException: Collection was modified 异常就会迎面而来。毫不夸张地说，这是几乎每个C#开发者都踩过，或即将踩到的第一个坑。

为什么 foreach 里动不得 List？

要理解这个异常，得看看 foreach 的底牌。它底层依赖于 IEnumerator 接口。迭代开始时，枚举器会悄悄记下集合内部的一个 version（版本号）字段。接下来，但凡你对集合进行任何结构性修改——无论是 Add、Remove 还是 Clear——都会导致这个 version 自增。于是，当循环执行到下一次 MoveNext() 时，枚举器一核对版本号：“不对，这集合跟我刚开始认识的时候不一样了！” 便会立刻抛出异常。

这带来的典型困扰是：

• 你的代码逻辑看起来天衣无缝（“找到那个符合条件的项，然后 list.Remove(item)”），但运行时却报错。
• 更让人头疼的是，错误堆栈往往指向 foreach 内部隐式调用的 MoveNext()，而不是你写 Remove 的那一行代码，排查时很容易找错方向。

需要边遍历边删除？试试反向 for 循环

当删除操作不可避免时，一个经典且高效的解决方案是：改用反向 for 循环，从列表的末尾开始，向前遍历。

for (int i = list.Count - 1; i >= 0; i--)
{
    if (list[i].ShouldBeRemoved)
        list.RemoveAt(i);
}

这个方法之所以靠谱，原因在于：

• 通过索引直接访问 list[i]，完全绕开了 foreach 那套版本检查机制。
• 从后往前删，即使删除了当前元素，后面（索引更小）待检查的元素只会向前移动位置，而你的循环变量 i 正在递减，完美避开了索引错位或元素被跳过的问题。
• 相比后面会提到的 ToList() 方案，这是原地操作，没有额外的内存分配，对于大型列表尤其友好。

这里有个关键提醒：千万别用正向的 for 循环（i++）搭配 RemoveAt(i)。想象一下，当你删除索引为 i 的元素后，原来在 i+1 位置的元素会补位到 i 的位置。但此时循环已经执行了 i++，导致这个新补位来的元素被彻底跳过，检查就漏掉了。

Where + ToList：清晰，但有代价

如果你的业务逻辑更倾向于“筛选出需要保留的元素”，而不是“逐个判断并删除”，那么使用LINQ的 Where 配合 ToList，代码会显得异常清晰：

list = list.Where(x => !x.ShouldBeRemoved).ToList();

不过，天下没有免费的午餐，这种写法的代价需要心里有数：

• 它创建了一个全新的列表对象，原来的 list 引用被替换了。如果代码其他地方还持有对旧列表的引用，它们指向的数据将不会同步更新，这可能引发隐蔽的bug。
• 内存开销瞬间翻倍（旧列表等待GC回收，新列表已经分配）。当处理一个巨大的 List 或者包含大对象的列表时，这种压力不容小觑。
• 性能上，它虽然是 O(n) 的时间复杂度，但引入了额外的GC压力。而反向 for 循环同样是 O(n)，却是原地操作，零额外分配。

所以，选择哪种方式，取决于场景。如果只是单纯地读取数据，foreach 依然是王者。如果删除逻辑复杂，涉及多重条件组合筛选，那么 Where 带来的可读性提升，可能比那点性能开销更值得。

小心那些“看起来只读”的陷阱：ReadOnlyCollection 与 IEnumerable

遍历的坑，有时不在遍历本身，而在你拿到的集合类型上。

当你的方法参数声明为 IEnumerable 时，调用者传进来的可能是一个实实在在的 List，也可能是一个基于 yield return 的惰性枚举序列。对于后者，每次遍历都可能触发一次实际计算（比如每次 MoveNext 都去查一次数据库）。如果你需要多次遍历这个序列，明智的做法是先调用 .ToList() 将其结果缓存起来。

另一方面，关于“只读”保护：

• list.AsReadOnly() 返回的 ReadOnlyCollection，提供的是一种“契约式”的只读。通过反射或者简单的强制类型转换，外部代码依然有可能修改其底层数据。它并非铜墙铁壁。
• 如果你需要真正不可变的集合来防止外部修改，应该返回一个列表的副本（new List(list)），或者考虑使用 System.Collections.Immutable 命名空间下的 ImmutableList。

实际开发中最棘手的，往往是那些你以为“只是读取”的方法，内部却悄无声息地调用了 Remove 或 Clear，而且文档里只字未提。所以，当你遇到诡异的 Collection was modified 异常时，第一反应应该是：检查整个调用链，看看有没有哪个“老实人”在背地里偷偷修改了你的集合。