yield return 仅适用于按需生成、逐个返回的场景，如流式读取大文件、递归遍历目录树、无限序列生成、分页查询数据库；在已具现化集合时应直接返回，避免无谓开销。
yield return 该用在哪些真实场景里
只在需要「按需生成、逐个返回」时才用，不是所有返回集合的地方都适合。比如你已经在内存里建好了 List<string></string>，直接 return list 更快更安全；加一层 yield return 反而引入状态机开销，还可能让调用方误以为是惰性求值。
真正值得用的场景有：
- 流式读取大文件：
ReadLinesChunked(string path)每次yield return一行，不把整个文件加载进内存 - 递归遍历目录树：
EnumerateFilesRecursive(DirectoryInfo root)边走边吐FileInfo，避免栈溢出或内存暴涨 - 无限序列生成：比如斐波那契数列，
yield return能天然支持Take(100)这类 LINQ 截断 - 分页查询数据库：每次
yield return一页结果，配合yield break控制终止条件
常见编译错误和为什么报错
写 yield return 方法时，编译器会严格检查上下文。一旦违反规则，立刻报错，不是运行时报——所以别等调试才发现。
-
CS1626：在try块里写了yield return→ 编译器禁止，因为异常处理逻辑和状态机生命周期冲突 -
CS1625：在finally块里用了yield return→ 同样被禁，finally代码不会被状态机捕获执行 -
CS1631：在catch块里yield return→ 不允许，异常分支不能参与迭代流 -
CS1627：写了yield return;（没表达式）→ 必须带值，yield return null或yield return default(T)才合法 -
CS1624：方法返回类型不是IEnumerable<t></t>或IEnumerator<t></t>→ 比如误写成List<t></t>或void，编译直接拒
容易被忽略的运行时行为
很多问题不是编译不过，而是运行起来“不对劲”，根源在于状态机机制不透明。
- 多次调用同一个
yield方法，每次都会重新执行全部逻辑（比如重查数据库），不是共享缓存 → 需要缓存时得手动包一层.ToList() - 在循环中复用同一个对象实例再
yield return，结果所有元素都指向最后一个值 → 应该每次新建：yield return new FileInfo(p).FullName，而不是先赋值给局部变量再返回 -
yield break不等于return：它只是告诉迭代器“没东西了”，后面代码仍会执行 →Console.WriteLine("This still runs!")真的会打印 - 在
foreach中修改外部集合，再继续迭代该yield方法的结果 → 报InvalidOperationException: Collection was modified，这不是 bug，是设计使然
性能与兼容性底线
别为了语法糖牺牲可维护性和确定性。
- 首次调用
yield方法不执行任何逻辑，直到第一次MoveNext()→ 适合延迟初始化，但别指望它“预热” - 每次
MoveNext()都有状态机跳转成本，别在高频循环（hot path）里用，比如每帧渲染中生成坐标序列 - .NET Framework 2.0+ 和 .NET Core 1.0+ 都支持，但
async+yield return不行 → 要异步迭代必须用IAsyncEnumerable<t></t>+await foreach -
yield return方法不能有ref参数、不能返回ref、不能含不安全代码（unsafe块）、不能捕获ref局部变量 → 这些都会触发CS8154、CS9238等错误
最常被低估的一点：yield return 方法本质是编译器帮你生成一个私有状态机类，实现 IEnumerator<t></t>。你看到的是简洁语法，背后是完整对象生命周期和字段捕获逻辑——写的时候得时刻想着“这个变量会不会被下次迭代看到新值”。
