说白了吧，yield return 只在一种场景下值得用：当你需要按需生成、逐个返回数据的时候。比如流式读大文件、递归遍历目录、无限序列、分页查询——这些场景天生适合它。但如果你手里已经有一个现成的 List，直接 return list 就好，千万别为了用 yield 而用 yield，那只会增加不必要的开销，还容易让调用方误解为惰性求值。
yield return 该用在哪些真实场景里
哪些场景才是真正值得用 yield return 的地方？这里有几个典型例子：
- 流式读取大文件：比如
ReadLinesChunked(string path)，每次只返回一行，不会把整个文件一股脑塞进内存。 - 递归遍历目录树：
EnumerateFilesRecursive(DirectoryInfo root)边走边吐FileInfo，既避免了栈溢出，也防止内存暴涨。 - 无限序列生成：斐波那契数列这类场景，
yield return天然支持Take(100)这样的 LINQ 截断操作，非常干净。 - 分页查询数据库：每次只返回一页结果，配合
yield break控制终止条件，逻辑清晰又高效。
常见编译错误和为什么报错
写 yield return 方法时，编译器会像一个严格的老师，一旦发现不合规的地方，立刻报错——这些错误都是编译时就能发现的，别等调试才来找。来看几个常见的：
- CS1626：在
try块里写yield return？不行，因为异常处理逻辑和状态机生命周期会打架。 - CS1625：
finally块里也不能用yield return，finally代码不会被状态机捕获执行。 - CS1631：
catch块里同样不允许，异常分支不能参与迭代流。 - CS1627：
yield return;不带表达式？必须带值，yield return null或yield return default(T)才合法。 - CS1624：方法返回类型不是
IEnumerable或IEnumerator？比如误写成List或void，编译直接拒绝。
容易被忽略的运行时行为
除了编译错误，运行时的一些行为也容易让人困惑。这些问题的根源在于 yield return 背后的状态机机制不透明。
- 多次调用同一个
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 return 时，别为了语法糖牺牲可维护性和确定性。有几个性能底线需要注意：
- 首次调用
yield方法时，不会执行任何逻辑，直到第一次MoveNext()才真正开始。这适合延迟初始化，但别指望它能帮你“预热”。 - 每次
MoveNext()都有状态机跳转成本，别在高频循环（hot path）里用。比如每帧渲染中生成坐标序列，用yield return就是给自己挖坑。 - .NET Framework 2.0+ 和 .NET Core 1.0+ 都支持，但
async+yield return不行。要异步迭代，必须用IAsyncEnumerable+await foreach。 yield return方法不能有ref参数、不能返回ref、不能包含不安全代码（unsafe块）、不能捕获ref局部变量。这些都会触发CS8154、CS9238等错误。
最常被低估的一点：yield return 方法本质上是编译器帮你生成一个私有状态机类，实现 IEnumerator。你看到的是简洁语法，背后是完整的对象生命周期和字段捕获逻辑。写的时候得时刻想着：“这个变量会不会被下次迭代看到新值？”
