返回 ienumerable 表示“可被 foreach”，不缓存结果，每次遍历都重新执行（如查库两次）；滥用致重复计算、内存暴涨或线程卡死，应依需用 tolist/toarray 或 any，慎用 yield return 与同步 i/o。
返回 IEnumerable<t></t> 不等于“返回一个列表”，它只表示“我能被 foreach”，背后可能是一次数据库查询、一行行读文件，甚至还没开始执行。滥用会导致重复计算、内存暴涨或线程卡死。
为什么调用两次 foreach 会查两次数据库？
因为 IEnumerable<t></t> 默认不缓存结果，每次遍历都重新触发整个迭代逻辑。比如你写：
var users = dbContext.Users.Where(u => u.IsActive).Select(u => u.Name); // 没执行 foreach (var name in users) Console.WriteLine(name); // 第一次：发 SQL foreach (var name in users) Console.WriteLine(name); // 第二次：再发一遍 SQL
常见误判点：
- 以为
.Where()或.Select()立即执行 —— 实际只是构建表达式树或迭代器状态机 - 在日志、监控、权限校验等场景里无意中多次消费同一个
IEnumerable<t></t> - 用
.Count()判断是否为空后再遍历 → 强制执行一轮，再执行第二轮
解决办法：确认需要多次访问时，显式调用 .ToList() 或 .ToArray()；若只是判断非空，改用 Any()。
yield return 实现的迭代器为什么容易卡主线程？
每次 MoveNext() 都会恢复方法执行，直到下一个 yield return 或方法结束。如果中间夹了同步 I/O，就会阻塞。
典型错误写法：
public IEnumerable<string> ReadLines(string path)
{
var all = File.ReadAllLines(path); // ⚠️ 一次性加载全部，大文件直接卡死
foreach (var line in all) yield return line;
}</string>
更隐蔽的坑：
- 在
yield return方法里调用HttpClient.GetStringAsync(...).Result→ 同步等待，UI 线程冻结 - 打开
FileStream但没用using包裹 → 枚举中途异常退出，句柄泄漏 - 混合
async和yield return→ 编译报错：Cannot use yield return in an async method
替代方案：C# 8+ 起该用 IAsyncEnumerable<t></t> + await foreach。
自定义类实现 IEnumerable<t></t> 时最容易漏掉什么？
必须同时提供泛型和非泛型两个 GetEnumerator() 方法，否则 foreach 编译失败。
正确结构：
public class BookCollection : IEnumerable<string>
{
private readonly List<string> _books = new() { "C# in Depth" };
<pre class="brush:php;toolbar:false;">public IEnumerator<string> GetEnumerator() => _books.GetEnumerator();
// 这个不能少，且必须显式转换（不能只写 return GetEnumerator();）
IEnumerator IEnumerable.GetEnumerator() => GetEnumerator();</string>
}
常见疏忽：
- 只实现泛型版，忘了非泛型版 → 编译错误：
Foreach statement cannot operate on variables of type ... because ... does not contain a public instance definition for 'GetEnumerator' - 非泛型版直接
return GetEnumerator();→ 类型不匹配，编译不过 - 内部数据不是
List<t></t>（比如是字典或链表），却盲目转发.GetEnumerator()→ 输出顺序不符合预期，应改用yield return显式控制
.ToList() 和 .ToArray() 的真实开销在哪？
它们不只是类型转换，而是强制执行整个迭代链，并把所有元素装进新容器。代价来自三块：内存分配、CPU 遍历、潜在的重复 IO 或计算。
关键细节：
-
.ToList()初始容量为 4，后续扩容按 2 倍增长；若预估有 10000 条，建议写new List<string>(10000)</string>避免反复拷贝 -
.ToArray()对无ICollection<t></t>实现的IEnumerable<t></t>（如纯yield return）会先遍历一次估算长度，再遍历一次填充 → 实际执行两轮 - 若上游是 LINQ to Entities 查询，
.ToList()会把整张表拉到内存再过滤 → 应优先把.Where()等条件留在数据库端
最常被忽略的一点：你以为自己只“转了个类型”，其实已经把延迟执行彻底破坏了 —— 后续所有优化（如分页、投影、服务端计算）全失效。
