ToLookup比GroupBy更适合反复按键查数据，因其立即执行并返回支持索引器的ILookup，可O(1)安全查找；GroupBy延迟执行且不支持索引访问，每次查找需遍历。
为什么 ToLookup 比 GroupBy 更适合反复按键查数据
因为 ToLookup 是立即执行的，返回一个支持索引器访问的只读结构 ILookup；而 GroupBy 返回的是延迟执行的 IEnumerable，不支持 lookup["key"] 这种写法。
常见错误现象：groups["Electronics"] 编译失败，报错 CS0021 Cannot apply indexing with [] to an expression of type 'IEnumerable —— 这说明你误把 GroupBy 结果当成了可索引的查找表。
使用场景：需要在循环中多次根据 Key 获取对应元素集合（比如按部门查员工、按首字母查单词列表），这时 ToLookup 只分组一次，后续每次 lookup[key] 都是 O(1) 查找；而如果用 GroupBy + FirstOrDefault(g => g.Key == key)，每次都会遍历整个分组序列。
四种重载怎么选：keySelector 是必须的，elementSelector 和 comparer 是可选的
ToLookup 有 4 个重载，核心区别在于是否需要转换元素值、是否需要自定义键比较逻辑：
-
source.ToLookup(x => x.Department)：最常用，只按某属性分组，值保持原对象 -
source.ToLookup(x => x.Department, x => x.Name)：分组后只保留姓名字符串，不保留整个对象 -
source.ToLookup(x => x.Category, StringComparer.OrdinalIgnoreCase)：忽略大小写分组 -
source.ToLookup(x => x.Category, x => x.Id, StringComparer.OrdinalIgnoreCase)：同时指定键比较器和元素投影
注意：没有 resultSelector 重载（不像 GroupBy），所以无法像 GroupBy(..., (k, g) => new { Key = k, Count = g.Count() }) 那样直接构造新对象。如需这类结果，得先 ToLookup 再手动映射。
ILookup 的索引器行为：查不到 Key 时返回空集合，不会抛异常
ILookup 的 this[TKey key] 索引器设计得很安全：即使 key 不存在，也返回一个空的 IEnumerable，而不是 null 或抛 KeyNotFoundException。
这意味着你可以放心写：
var lookup = people.ToLookup(p => p.Gender);
foreach (var name in lookup["Unknown"]) { /* 安全，不会崩 */ }
但要注意：这个“空集合”不是 null，所以 lookup["Unknown"]?.Count() 会正常返回 0；而 lookup["Unknown"].Any() 也是安全且高效的（不需要枚举全部）。
容易踩的坑：有人误以为 lookup.ContainsKey("X") 存在 —— 实际上 ILookup 没有这个方法，只能用 lookup["X"].Any() 替代。
性能与内存开销：ToLookup 会立刻遍历并建哈希表，别在大数据源上盲目调用
ToLookup 一调用就遍历整个源集合，构建内部哈希表结构，并把所有匹配项缓存下来。这对小到中等数据（几千条以内）很友好，但对超大集合（如百万级日志行）可能带来明显内存和 CPU 开销。
几个关键点：
- 它不支持分页或流式处理，必须一次性加载全部数据
- 如果只是临时查一两次，且源集合本身很小，影响不大
- 如果后续只用部分 Key，却为所有 Key 建了桶，属于隐性浪费
- 对比
GroupBy：后者在foreach前都不干活，更适合“可能不执行”的场景
真正容易被忽略的是：哪怕你声明了 var lookup = bigList.ToLookup(...) 却完全没访问它，分组动作也已经发生了 —— 这和 GroupBy 的惰性截然不同。
