yield return 仅适用于按需生成、逐个返回的场景，如流式读取大文件或遍历树结构；若数据已在内存中，直接返回集合更高效，避免状态机开销和并发修改异常。
yield return 什么时候该用，什么时候不该用
它只适合封装「按需生成、逐个返回」的逻辑，比如读大文件时一行行 yield，或递归遍历树结构时边走边吐节点。如果数据早已在内存里攒好了（比如 List<int></int>），直接 return list 更快更直观——加一层 yield return 反而引入状态机开销，还让调用方误以为是“懒求值”。
常见错误现象：foreach 里修改了 yield 方法返回的集合，结果报 InvalidOperationException: Collection was modified。这不是 bug，是设计使然：yield 方法每次调用都新建迭代器，但底层集合若被外部改了，下次迭代就崩。
- 使用场景：分页查数据库、流式解析 JSON 数组、生成斐波那契无限序列
- 性能影响：首次调用不执行方法体，真正
MoveNext()才运行到第一个yield return；但每次迭代都有状态机跳转成本，别在 hot path 上滥用 - 兼容性：.NET Framework 2.0+ / .NET Core 1.0+ 都支持，但 yield 方法不能是 async（得用
IAsyncEnumerable<t></t>+await foreach）
yield break 的实际作用不是“提前退出”，而是“结束迭代”
yield break 不等于 return，它不返回值，也不终止当前方法执行（后面代码仍可能跑），只是告诉迭代器：“这里没东西了，MoveNext() 下次该返回 false”。很多人写成这样：
public IEnumerable<string> GetNames()
{
if (names == null) yield break;
foreach (var n in names) yield return n;
}</string>
这没问题；但如果写成：
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——它不会，因为迭代器状态机把finally拆到 MoveNext() 外层了 - 不能在
catch中yield return后再yield break，编译器会报错：“控制不能离开迭代块” - 空集合推荐直接
yield break，而不是yield return default(T)再 break，语义更干净
IEnumerable 和 IEnumerator 的分工必须理清
写 yield 方法，本质是让编译器帮你生成一个私有嵌套类，实现 IEnumerator<t></t>；而方法签名返回的 IEnumerable<t></t> 是工厂接口，每次调用都 new 出新迭代器。这意味着：
- 多次
foreach同一个yield方法结果，会重复执行逻辑（比如重查数据库），不是共享一份缓存 - 不能把
yield方法结果存成字段反复用——它不是数据容器，是“生成器” - 想缓存结果？显式调用
.ToList()或.ToArray()，但注意内存占用
参数差异：yield 方法本身不能带 ref 或 out 参数（编译器不许），但可以接收普通参数并闭包捕获——这点常被忽略，导致闭包变量生命周期意外延长。
调试 yield 方法为什么总跳不到断点
因为编译器把它重写成了状态机类，原始方法体只在构造迭代器时运行一次（且只到第一个 yield 就停），后续断点得打在状态机的 MoveNext() 里——VS 默认不显示这些生成代码，所以看着像“断点失效”。
实操建议：
- 在
yield return行设断点，运行时确保是在foreach第一次迭代（即第一次MoveNext()）才命中 - 用
DebugView或反编译工具（如 ILSpy）看生成的状态机类，确认逻辑分支是否符合预期 - 别在 yield 方法里写复杂初始化逻辑——它会在每次 GetEnumerator() 时执行，包括被 LINQ 操作符隐式调用时，容易引发重复副作用
最常被忽略的一点：yield 方法里的局部变量，其生命周期绑定到迭代器实例，不是方法调用栈。一旦你把迭代器传出去、缓存起来，那些变量就一直活着，可能造成意料外的内存驻留。
