yield return 本质是编译器生成实现 IEnumerable<T> 和 IEnumerator<T> 的状态机类，支持延迟执行但每次 GetEnumerator() 都新建实例；适用于流式、大开销或未知大小的数据源，需避免闭包陷阱与跨线程误用。
yield return 本质是编译器帮你写了一个状态机
它不是语法糖，而是 c# 编译器在背后生成了一个实现了 ienumerable<t> 和 ienumerator<t> 的匿名类。你写的每个 yield return 都会被转成一个状态跳转点，所以它天然支持延迟执行、按需计算——但代价是每次调用 getenumerator() 都会新建一个状态机实例。
- 函数返回类型必须是
IEnumerable<T>、IEnumerator<T>或其泛型变体，不能是List<T>或数组 - 函数体内不能有
return value;（非 void 返回值），只能用yield return或yield break - 局部变量、参数、
try/catch块都会被提升到状态机类的字段里，调试时看到的“变量作用域”和直觉可能不一致
什么时候该用 yield return，而不是 new List<T>().Add()
核心判断标准就一条：数据源是流式、不可预知大小、或构造开销大（比如读文件、查数据库、递归遍历树）。
- 查数据库后逐条处理：用
yield return可避免一次性加载全部结果到内存；用List<T>则可能 OOM - 递归遍历二叉树：用
yield return写中序遍历，代码简洁且栈空间友好；改成 List 就得自己维护栈，还容易漏 yield 子节点 - 如果数据量小（List<T> 更快，因为免去了状态机分配和状态切换开销
yield return 在 async 方法里不能直接用
这是最常踩的坑：async Task<IEnumerable<T>> + yield return 会编译失败，错误信息是 CS1929：“无法将类型‘IAsyncEnumerable<T>’转换为‘IEnumerable<T>’”。
- 解决方案只有两个：
– 改用IAsyncEnumerable<T>+yield return（C# 8+，需async+yield return，返回类型必须是IAsyncEnumerable<T>）
– 或者老老实实 await 后把结果 collect 成List<T>再返回 -
IAsyncEnumerable<T>的yield return不是简单加个 async 就行——它底层是基于await foreach和ConfiguredCancelableAsyncEnumerable，调度行为和同步版完全不同 - 别试图用
Task.Run(() => { yield return ……})绕过，这会导致状态机在后台线程创建，极易引发上下文丢失或跨线程访问异常
调试 yield return 函数时看不到中间值？
因为状态机是懒执行的：不走到 MoveNext()，就不会运行到对应 yield return 行。断点打在 yield return x; 上，第一次进不去；要等 foreach 或显式调用 enumerator.MoveNext() 才触发。
- 想看每一步输出，别只依赖断点，加
Console.WriteLine($"yielding: {x}");更可靠 - VS 调试器对状态机的“当前状态”显示有限，有时显示“state = -1”表示还没开始，“state = 1”表示刚 yield 第一个值，数值含义和代码顺序强相关，但不直观
- 如果函数里用了闭包（比如捕获了 for 循环变量），注意所有
yield return共享同一个变量实例——常见 bug 是所有项都返回最后一轮的值
实际用的时候，最容易被忽略的是状态机的生命周期和闭包变量绑定方式——它不像普通方法那样“每次调用都是干净的栈帧”，而是一个对象复用多个字段来模拟暂停 / 恢复。写完最好跑一遍 foreach + ToList() 对比，确认行为符合预期。
