yield return 是编译器生成状态机的开关，适用于数据未就绪或不宜全加载场景，如流式读取、树遍历、分页查询和无限序列；误用会导致性能下降、并发异常及调试困难。
yield return 不是语法糖，它是编译器生成状态机的开关；用错地方反而拖慢性能、引发并发异常，甚至让逻辑难以调试。
yield return 适合什么场景
它只在「数据还没准备好」或「不该一次性全加载」时才该用：
- 流式读取大文件，比如逐行
yield return解析 CSV，避免File.ReadAllLines()把几 GB 内存撑爆 - 递归遍历树结构（如文件系统、DOM 节点），边 DFS 边吐节点，不建中间集合
- 分页查数据库，每次
yield return一页结果，配合yield break在无更多数据时终止 - 生成无限序列，比如
Fibonacci()或带步长的整数范围，调用方决定取多少个
关键判断标准：调用方是否真的需要「懒求值」？如果所有数据早已在内存里（比如 List<int></int> 已填充完毕），直接 return list 更快、更安全、更易理解。
yield break 不是 return，也不会跳过后续代码
yield break 的作用只是通知迭代器：「本次迭代到此为止，MoveNext() 下次该返回 false」。它不退出方法，也不触发 finally 块：
public IEnumerable<string> GetNames()
{
if (names == null)
yield break;
Console.WriteLine("This still runs!"); // ✅ 真的会执行
foreach (var n in names)
yield return n;
}</string>
常见错误写法：
- 在
try块里写yield break期望清理资源？不行——finally不会在迭代器状态机中按预期执行 - 在
catch中yield return后再yield break？编译器直接报错：Control cannot leave the iterator block - 空集合返回
yield return default(T)再yield break？语义混乱，应直接yield break
为什么 foreach 里改集合会崩：InvalidOperationException
这不是 bug，是设计使然。每次调用 yield 方法都会新建一个迭代器实例，但它背后共享的是同一个底层集合。一旦你在 foreach 循环中修改了这个集合（比如 list.Add() 或 list.Remove()），下一次 MoveNext() 就会抛 Collection was modified。
根本原因：迭代器状态机在运行时检查集合版本号（_version），不一致就炸。解决办法只有两个：
- 确保迭代期间集合不可变（最安全）
- 若必须边遍历边改，先
ToList()快照一份再操作，但注意这失去懒求值意义
别指望加锁能绕过——yield 方法本身不是线程安全的，状态机没做同步封装。
async + yield 不行，得换 IAsyncEnumerable
yield 方法不能是 async，编译器会拒绝：
// ❌ 编译错误：Iterator methods cannot be async
public async IEnumerable<string> ReadLinesAsync()
{
await Task.Delay(100);
yield return "line1";
}</string>
要实现异步迭代，必须用 IAsyncEnumerable<t></t> + yield return（C# 8.0+）：
public async IAsyncEnumerable<string> ReadLinesAsync()
{
await foreach (var line in File.ReadLinesAsync("log.txt"))
yield return line.Trim();
}</string>
注意：消费端也得用 await foreach，且运行时需 .NET Core 3.0+ 或 .NET 5+。老项目升级前务必确认目标框架。
真正容易被忽略的点在于：yield 方法看似简单，实则把执行时机、状态保存、异常传播、资源生命周期全都交给了编译器生成的状态机——你写的每行代码，都可能在 MoveNext() 的不同阶段被拆开执行。不理解这点，就容易把迭代器当普通方法用，然后花半天 debug 为什么某句日志没打、某个 Dispose() 没调用、或者集合突然报错。
