C#中LINQ GroupBy、手动字典聚合与LINQ分组的差异及选型

我有一个C#控制台应用，需要把CSV文件中的数据读取为对象列表，每行对应一个关联了事件名称的按钮。现在要生成统计数据，展示每个事件在文件中的出现次数。

数据加载代码如下：

var buttons = File.ReadAllLines("buttons.csv")
                  .Select(x => x.Split(';'))
                  .Select(x => new MyButton(
                      x[0],
                      int.Parse(x[1]),
                      int.Parse(x[2]),
                      int.Parse(x[3]),
                      int.Parse(x[4]),
                      x[5]))
                  .ToList();

MyButton类定义：

class MyButton
{
    public string MyEvent { get; set; }
}

我实现了三种统计方式，但不清楚它们的实际差异：

1. LINQ GroupBy + ToDictionary #

var stats = buttons
    .GroupBy(b => b.MyEvent)
    .ToDictionary(g => g.Key, g => g.Count());

2. 手动字典聚合 #

Dictionary<string, int> stats = new Dictionary<string, int>();

foreach (var button in buttons)
{
    if (stats.ContainsKey(button.MyEvent))
        stats[button.MyEvent]++;
    else
        stats[button.MyEvent] = 1;
}

3. LINQ分组直接投影 #

var stats = buttons
    .GroupBy(b => b.MyEvent)
    .Select(g => new { Event = g.Key, Count = g.Count() });

提问 #

这三种C#实现方式的实际差异是什么？在可读性、性能和惯用性方面，哪种在实际代码中更受青睐？

一、核心差异 #

1. 返回类型不同 #

• 方式1：返回Dictionary<string, int>，键是事件名，值是次数，支持直接通过事件名快速查找次数（O(1)时间复杂度）。
• 方式2：同样返回Dictionary<string, int>，最终结果和方式1完全一致，但实现逻辑是手动遍历控制。
• 方式3：返回IEnumerable<匿名类型>，每个元素包含Event和Count属性，本质是分组后的序列，不支持直接按键查找，需要遍历或转成字典才能快速查询。

2. 实现逻辑不同 #

• 方式1：利用LINQ的GroupBy先按事件名分组，再通过ToDictionary把分组结果转成字典，是LINQ封装的实现逻辑。
• 方式2：手动遍历集合，通过ContainsKey判断键是否存在，不存在则初始化计数为1，存在则自增，完全是手动控制的循环逻辑。
• 方式3：仅用GroupBy分组后，投影成包含键和计数的匿名对象序列，保留了LINQ的延迟执行特性（除非后续枚举，否则不会实际计算）。

二、可读性对比 #

• 方式1：代码简洁，用LINQ链式调用直接表达“分组后转字典统计次数”的意图，熟悉LINQ的开发者一眼就能看懂，可读性很高。
• 方式2：逻辑直白，适合刚接触C#、不熟悉LINQ的开发者，每一步操作都清晰可见，但代码行数更多，显得繁琐。
• 方式3：同样是LINQ链式调用，表达“分组后获取每个组的键和计数”的意图，但返回的是序列而非字典，需要注意后续使用场景，可读性不错，但比方式1少了“转字典”的明确意图。

三、性能对比 #

• 小数据量：三种方式性能差异可以忽略不计，几乎没有区别。
• 大数据量：
  • 方式2通常性能最优，因为它只遍历一次集合，没有LINQ带来的额外封装开销，ContainsKey+索引访问的操作效率也很高。如果用.NET 6+的TryAdd优化代码，性能还能进一步提升：

    foreach (var button in buttons)
    {
        if (!stats.TryAdd(button.MyEvent, 1))
            stats[button.MyEvent]++;
    }
    

    TryAdd比ContainsKey+索引访问更高效，因为它只做一次哈希表查找。
  • 方式1的性能略低于方式2，因为GroupBy内部会先遍历集合生成分组，然后ToDictionary又要遍历一次分组结果，相当于两次遍历，而且LINQ的委托调用会有轻微的性能损耗。
  • 方式3的性能和方式1接近（GroupBy同样需要遍历集合），但如果只是一次性枚举输出统计结果，不需要查找，它的延迟执行特性可以节省提前计算的开销；如果需要多次查询，不如转成字典高效。

四、惯用性对比 #

• 在现代C#开发中，方式1是最常用的写法，它兼顾简洁性和实用性，返回的字典能满足大多数场景下的查询需求，符合LINQ的惯用写法。
• 方式2更多出现在早期C#版本（LINQ出现之前）或者对性能要求极高的场景，现在除非有明确的性能瓶颈，否则一般不会优先选择。
• 方式3适合只需要一次性枚举统计结果（比如直接输出到控制台、写入文件）的场景，如果不需要后续按键查找，它的代码也很简洁，但实用性不如方式1广泛。

总结 #

• 如果需要后续通过事件名快速查询次数，优先选方式1，兼顾可读性和实用性；如果追求极致性能，用优化后的方式2。
• 如果只是一次性输出统计结果，不需要查询，方式3是更轻量的选择。
• 大多数日常开发场景下，方式1是最优解，既符合C#的惯用写法，又能满足绝大多数需求。

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