17370845950

在绝大多数C#场景下，List.ForEach比传统for循环稍慢，因其本质是封装了for循环加委托调用，每次迭代需通过Action间接执行，产生额外跳转开销。

foreach 循环比 for 循环慢吗？

在绝大多数 C# 场景下，List.ForEach 和传统 for 循环的性能差异可以忽略不计，但 ForEach 确实有额外开销：它本质是封装了 for 循环 + 委托调用。每次迭代都要通过委托（Action）间接执行逻辑，而原生 for 是直接调用，无跳转成本。

List.ForEach 的实际开销在哪

List.ForEach 内部仍是 for (int i = 0; i 实现，但它强制你把业务逻辑包装成委托 —— 这带来两个隐性成本：

• 委托对象分配（.NET 5+ 对闭包和无捕获 lambda 有优化，但仍有调用开销）
• 无法内联（JIT 通常不会内联跨委托的调用）
• 不能提前退出（没有 break 或 continue，想中断必须抛异常或改用其他结构）

例如下面两段逻辑语义相同，但后者更轻量：

list.ForEach(x => {
    if (x == target) found = true;
});

for (int i = 0; i < list.Count; i++) {
    if (list[i] == target) {
        found = true;
        break; // ✅ 可中断
    }
}

什么情况下 for 明显更快

当循环体极简单、且数据量极大（如百万级 int 列表），或者你在高频路径（如游戏帧更新、实时音频处理）中使用时，for 的优势会显现：

• 访问 list[i] 比 foreach 的枚举器（IEnumerator）少一次字段读取和边界检查（List 的 for 已跳过部分验证）
• for 可配合 Span 或数组直接操作（list.AsSpan()），彻底绕过索引器开销
• 若需同时访问索引和元素（如 i 和 list[i]），for 避免重复计算或额外变量

别为了微秒牺牲可读性和安全性

除非 profiler 明确指出该循环是瓶颈，否则优先选语义清晰、不易出错的方式：

• 遍历只读场景 → foreach（含 List.ForEach）更直观
• 需要索引/修改/中断/多集合协同 → 用 for
• 极端性能敏感 → 改用 Span + for，并禁用边界检查（#pragma unsafe 或 MemoryMarshal.GetArrayDataReference）

真正影响性能的往往不是循环语法本身，而是循环体内是否触发装箱、GC 分配、虚拟调用或 IO 等 —— 先看这些地方。