IEnumerable意外行为：AzureDevOps数据映射中ToList()影响性能的原因

核心问题出在LINQ的延迟执行特性，以及两种情况下查询执行的时机和次数差异：

1. 不调用.ToList()时的性能灾难 #

当codeReviewResponseIds不调用.ToList()时，它只是一个未执行的LINQ查询对象（IEnumerable<int>），并没有实际生成数据：

• 每次调用codeReviewResponseIds.Contains(x.fields.SystemId)时，都会重新执行一遍workItemRelations?.workItemRelations.Where(...).Select(...)的逻辑——也就是全量扫描workItemRelations集合，筛选出当前codeReviewId对应的所有target.id。
• 再加上mapDictionary中存储的IEnumerable<CodeReviewResponse>也是延迟执行的查询，当后续遍历Excel转换时，每遍历一个CodeReviewResponse对象，都会触发上述的重复扫描。
• 假设workItemRelations有N条数据，workItemBatchResponses有M条数据，总操作复杂度会达到O(N*M)，数千个对象的情况下就是几十万次重复遍历，耗时自然急剧上升。

2. 调用.ToList()时的性能提升 #

调用.ToList()会立即执行LINQ查询，把筛选后的target.id一次性加载到内存的List<int>中：

• 后续的Count()、Contains()操作都是直接操作内存中的集合，不会再去扫描原workItemRelations数据源。
• 此时Contains的操作复杂度变为O(K)（K是当前codeReviewId对应的响应ID数量，远小于N），总操作复杂度降到O(M*K)，性能大幅提升。

额外优化建议 #

如果要彻底消除延迟加载对后续模块的影响，建议把mapDictionary的值也提前加载到内存，也就是给最终的查询结果加上.ToList()：

mapDictionary[codeReviewId] = workItemBatchResponses
    .SelectMany(x => x.value)
    .Where(x => codeReviewResponseIds.Contains(x.fields.SystemId))
    .ToList();

这样后续转换Excel时，直接遍历内存中的集合，不会再触发任何LINQ查询的重复执行。

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