yield return 方法调用时不执行，仅在首次枚举（如 foreach、First()）时触发状态机逐个执行；需避免将初始化逻辑误置于方法开头，且 IEnumerable 不支持索引访问。
yield return 什么时候真正执行
调用一个返回 IEnumerable<t></t> 的 yield return 方法时，**什么都不会发生**——没有计算、没有日志、没有异常，甚至连方法体第一行代码都不会跑。只有当结果被枚举（比如 foreach、ToList()、First()、甚至 .Count()）时，状态机才开始逐个触发 yield return 语句。
这意味着：如果你在 yield return 前写了 Console.WriteLine("start")，它只会在第一次取值时打印；如果整个结果没被消费，这行就永远不执行。
- 常见错误：把耗时逻辑（如数据库查询、文件读取）写在
yield return方法开头，误以为“调用即执行”，结果调试时发现日志没打、超时没抛、连接没建 - 正确做法：把初始化逻辑尽量推迟到第一个
yield return之前但紧邻它，或拆成两步——先校验参数，再在首次迭代时建立资源 - 注意
yield break：它不是“提前返回”，而是“终止迭代”，后续仍可能被枚举（只是立刻结束），所以不能靠它做一次性清理
为什么 foreach 能用，但直接访问索引会报错
IEnumerable<t></t> 不提供 [i] 索引器，也不保证支持随机访问。你写的 yield return 方法返回的是一个编译器生成的状态机对象，它只实现 GetEnumerator() 和 MoveNext()，没有 Count 属性、没有 this[int i]。
想用索引？必须显式转换：var list = iterator.ToList() 或 var array = iterator.ToArray()。但这会强制全部执行并缓存所有元素——失去惰性求值的意义，还可能引发内存暴涨或重复 IO。
- 典型误用：
var result = GetNumbers(); Console.WriteLine(result[0]);→ 编译失败，因为IEnumerable<int></int>没有索引器 - 替代方案：若只需首个元素，用
result.First()（会执行到第一个yield return就停）；若需跳过前 N 个，用result.Skip(n).FirstOrDefault() - 性能陷阱：对大结果集反复调用
ToList()或ElementAt(i)，后者内部会从头遍历 i+1 次
IAsyncEnumerable 中的 yield return 和 await foreach 怎么配对
C# 8+ 的异步迭代器里，yield return 必须配合 async IAsyncEnumerable<t></t> 返回类型，且方法体内可安全使用 await。此时 yield return 不再返回即时值，而是返回一个“准备就绪后才交付”的异步信号。
await foreach 是唯一推荐的消费方式。它底层调用 GetAsyncEnumerator()，自动处理 MoveNextAsync() 和资源释放，不会阻塞线程。
- 错误写法：
foreach (var x in AsyncMethod())→ 编译失败，IAsyncEnumerable<t></t>不兼容同步foreach - 错误写法：
var list = await AsyncMethod().ToListAsync()→ 可能，但丢掉了流式处理优势；若数据源是网络流或事件流，提前缓存会导致延迟和内存压力 - 关键约束：异步迭代器中不能混用同步
yield return和await；所有yield return必须在await之后或之前，但不能跨await边界“保存局部变量状态”（编译器会报错）
Concat、GroupBy 这类 LINQ 方法怎么和 yield 配合不翻车
所有标准 LINQ 操作符（Where、Select、Concat、GroupBy 等）默认都保持延迟执行，它们包装你传入的 IEnumerable<t></t>，不立即触发 yield return 方法体。但有几个关键点极易踩坑：
-
Concat和Union本身不执行源序列，但一旦开始枚举结果，就会按顺序拉取第一个序列全部元素，再拉第二个——如果你的两个yield方法都含 IO，Concat会让第一个完全跑完才启动第二个，可能造成意外等待 -
GroupBy是“伪延迟”：定义时不执行，但**枚举第一个分组时，会一次性扫描整个源序列**（为建哈希表），所以它不节省内存，只节省“定义到执行”的时间差 - 链式调用如
source.Where(...).Select(...).Take(5)是安全的——Take(5)会让整个链在产出第 5 个元素后停止，前面的yield方法也只执行到那里 - 最隐蔽的坑：
Count()、Any()、ToList()这些终结方法会强制完整枚举，彻底破坏惰性；调试时随手加个.Count()查长度，可能让本该流式处理的百万行 CSV 全部加载进内存
实际项目里，yield return 的价值不在语法多炫，而在控制执行时机和资源生命周期。最容易被忽略的，是它把“何时打开数据库连接”“何时释放文件句柄”“何时触发网络请求”的决定权，从方法签名移交给了调用方的枚举行为——这个权责转移，稍不注意就会变成 bug 温床。
