该用 IEnumerable 当且仅当你只读、不修改、不反复遍历，且上游是延迟计算或流式生成的数据源；它是“能被 foreach”的契约，非容器，不保证随机访问或内存驻留。
什么时候该用 IEnumerable<t></t> 而不是 List<t></t> 或 Array
核心判断标准：你只读、不修改、不反复遍历，且上游数据源本身是延迟计算或流式生成的（比如数据库查询、文件逐行读取、递归树遍历）。IEnumerable<t></t> 是契约，不是容器 —— 它只承诺“我能被 foreach”，不承诺“我能随机访问”或“我已全部在内存里”。
常见误用场景：
- 方法返回
IEnumerable<t></t>，但内部实际构造了new List<t>()</t>并立即填充完所有数据 → 失去延迟执行意义，还多了一层抽象 - 调用方连续多次遍历同一个
IEnumerable<t></t>（如两次foreach或先.Count()再foreach）→ 若底层是 LINQ 查询或自定义迭代器，会重复执行整个逻辑（比如查两次数据库） - 把
IEnumerable<t></t>当作可变集合传入，然后试图调用.Add()或.Remove()→ 编译就报错，因为接口没定义这些方法
IEnumerable<t></t> 的 yield return 实现为什么容易卡住主线程
用 yield return 写的迭代器，代码块会在每次 MoveNext() 时“恢复执行”，直到下一个 yield return 或方法结束。这意味着：如果其中某次迭代触发了同步 I/O（比如读文件、发 HTTP 请求、等数据库响应），整个枚举过程就会阻塞当前线程。
典型陷阱：
- 在
yield return方法里调用File.ReadAllLines(path)→ 一次性加载全部内容，失去流式优势；更糟的是，若path是网络路径或大文件，会卡死 - 混合使用
async和yield return→ C# 不允许（编译错误：Cannot use yield return in an async method）。想异步流式产出，得换用IAsyncEnumerable<t></t>（C# 8+） - 迭代器内部有未释放的资源（如
FileStream、SqlConnection），且没有用using包裹 → 枚举中途异常或提前退出时，资源泄漏
IEnumerable<t></t> 上调用 .ToList() / .ToArray() 的真实开销在哪
这不是“简单转个类型”，而是强制执行整个迭代链，并把结果全部加载进内存。开销来自三方面：内存分配、CPU 遍历、以及可能的重复计算。
关键细节：
-
.ToList()初始容量默认为 4，后续扩容按 2 倍增长（类似List<t></t>行为），若预估数量大，建议用new List<t>(estimatedCount)</t>预分配 - 对已知长度的
IEnumerable<t></t>（比如数组或List<t></t>），.ToArray()会先调用ICollection<t>.Count</t>获取长度再分配数组；但对纯IEnumerable<t></t>（无Count实现），它会先遍历一次估算大小，再遍历一次填充 → 实际执行两轮 - 如果上游是
Where(...).Select(...)这类组合查询，调用.ToList()会触发完整管道执行；之后再对这个列表做筛选，就和原IEnumerable管道无关了
如何安全地调试或日志记录一个 IEnumerable<t></t>
直接 Console.WriteLine(myEnumerable) 只会输出类型名（如 WhereSelectEnumerableIterator`2），毫无信息量。想看内容，必须触发枚举，但又不能意外消耗掉它（尤其是一次性迭代器）。
实操建议：
- 临时调试用：写个扩展方法
.Peek(Console.WriteLine)，在yield return前打印值，且不改变原有逻辑流 - 生产环境避免：不要在日志里直接调用
.ToList().ToString()—— 大集合会 OOM，字符串拼接也慢；改用循环 + 限长（如只记前 10 项） - 注意副作用：若
IEnumerable<t></t>来自带副作用的迭代器（如调用外部 API），调试时枚举一次就发了一次请求，可能干扰业务逻辑
最常被忽略的一点：把 IEnumerable<t></t> 当作“轻量级接口”传参很安全，但一旦你开始调用它的扩展方法（.First()、.Any()、.Count()），就得立刻意识到——这些看似简单的操作，背后可能是全量扫描、甚至不可重入的 IO。别让它藏在抽象后面偷偷吃性能。
