tolookup不是groupby替代品，而是专为多次按键查找设计的立即执行分组工具；其返回ilookup支持索引器访问，查无key时返回空集合不抛异常，而groupby返回延迟执行的ienumerable，不支持[]索引，故groups["key"]编译报错cs0021。
直接说结论：ToLookup 不是 GroupBy 的替代品，而是专为「多次按 Key 查找」设计的立即执行分组工具；用错场景反而拖慢性能。
为什么 ToLookup["key"] 能编译通过，而 GroupBy["key"] 报 CS0021
因为 ToLookup 返回的是 ILookup<tkey telement></tkey>，它实现了索引器 this[TKey key]；GroupBy 返回的是 IEnumerable<igrouping telement>></igrouping>，纯枚举序列，没有索引能力。
- 常见错误现象：
groups["Electronics"]编译失败 → 实际就是把GroupBy结果当成了查找表 - 查不到 key 时，
lookup["Unknown"]返回空IEnumerable<telement></telement>，不是null，也不会抛KeyNotFoundException - 所以可以安全写
lookup["Unknown"].Any()或lookup["Unknown"].Count()，无需判空
四个重载怎么选：keySelector 是必须的，其他看需求
核心区别就三点：要不要改元素值、要不要忽略大小写、要不要自定义键比较逻辑。
-
source.ToLookup(x => x.Category)：最常用，只分组，保留原对象 -
source.ToLookup(x => x.Category, x => x.Name)：分组后只存姓名字符串，节省内存 -
source.ToLookup(x => x.Category, StringComparer.OrdinalIgnoreCase)：键忽略大小写（如 "user" 和 "USER" 归为一组） -
source.ToLookup(x => x.Category, x => x.Id, StringComparer.OrdinalIgnoreCase)：同时投影元素 + 自定义比较器
注意：ToLookup 没有 resultSelector 参数，不能像 GroupBy(..., (k, g) => new { Key = k, Count = g.Count() }) 那样一步构造聚合结果。需要先 ToLookup，再手动遍历每个组调 Count() 或 Sum()。
什么时候该用 ToLookup，而不是 GroupBy
关键判断依据是「访问模式」：如果你会反复根据 key 拿数据（比如在循环里查 10 次 lookup["DeptA"]），ToLookup 更合适；如果只是遍历一遍分组结果就结束，GroupBy 更轻量。
- 适合
ToLookup的场景：按部门查员工列表、按首字母查单词、缓存配置项分组、前端下拉筛选联动 - 不适合的场景：大数据源且不确定是否真要查 ——
ToLookup一调就全量扫描，哪怕你创建完就丢弃了 - 性能影响：200 万条记录下，
ToLookup构建耗时略高，但后续每次lookup[key]是 O(1)；GroupBy创建几乎零开销，但每次FirstOrDefault(g => g.Key == key)都要遍历整个分组序列
ILookup 看似像 Dictionary，但根本不是
它不实现 IDictionary，没有 ContainsKey、没有 TryGetValue，也没有线程安全保证。它的设计目标只有一个：支持快速、安全的多值索引访问。
- 别写
if (lookup.ContainsKey("X"))—— 编译不过，ILookup没这个方法 - 想判断是否存在某 key 对应的数据？直接用
lookup["X"].Any()，高效且语义清晰 - 它内部基于哈希表，但键重复时不会覆盖，而是追加 —— 所以天然支持一对多，不像
Dictionary那样要求 key 唯一
最容易被忽略的一点：ToLookup 是只读的，返回的 ILookup 无法 Add/Remove，也不提供任何修改接口 —— 它压根就不是容器，而是一次性构建的查找视图。
