C#迭代器由yield return声明，编译器自动生成状态机；手动实现IEnumerator易错难维护，而yield语法简洁、性能优、自动支持Dispose。
直接说结论：C# 中的迭代器不是“用”出来的，而是用 yield return 声明出来的；它背后由编译器生成状态机，不是手动实现 IEnumerable 或 IEnumerator —— 那样反而绕远、易错、难维护。
为什么不用手写 IEnumerator 类
手动实现 IEnumerator 要处理 Current、MoveNext()、Reset()、状态管理、异常边界（如多次调用 Reset()）、线程安全等细节。实际项目里几乎没人这么干，因为：
-
yield return写法更简洁、意图更清晰，比如遍历树节点、分页读取大文件、按需生成斐波那契数列 - 编译器生成的状态机已充分测试，性能不输手写（.NET 6+ 还做了内联优化）
- 手写容易漏掉
IDisposable支持（尤其涉及资源释放时），而yield方法在foreach结束或提前退出时会自动触发Dispose()
yield return 的基本写法和常见陷阱
最简形式就是返回一个可枚举序列，但要注意执行时机和作用域生命周期：
- 方法必须返回
IEnumerable<t></t>或IAsyncEnumerable<t></t>（后者需yield return+async+IAsyncEnumerable） -
yield return后不能有return语句（除了return;表示结束） - 不能在
try块中使用yield return，除非整个try在finally外（否则编译报错 CS1626） - 局部变量在
yield方法中会被捕获为状态机字段——如果变量是引用类型且被外部修改，后续yield返回时看到的是新值（常见于循环中误用同一变量实例）
例如这个典型错误：
public static IEnumerable<string> BadExample(string[] paths)
{
var item = new FileInfo("");
foreach (var p in paths)
{
item = new FileInfo(p); // ❌ 全部 yield 返回的都是最后一个 item
yield return item.FullName;
}
}应改为每次新建或直接计算值：yield return new FileInfo(p).FullName。
真实项目中迭代器的三个高频场景
不是为了炫技，而是解决具体问题：
-
流式读取大日志文件：避免一次性加载进内存
public static IEnumerable<string> ReadLinesChunked(string path, int bufferSize = 8192)</string>
逐块读、按行切分、yield return每行，调用方foreach时才真正读磁盘 -
递归遍历目录树（带过滤）：不用栈/队列手动维护状态
public static IEnumerable<fileinfo> EnumerateFilesRecursive(DirectoryInfo root, string pattern = "*.*")</fileinfo>
内部递归调用自身并yield return子结果，天然惰性、内存友好 -
API 分页拉取封装：把多页 HTTP 请求“伪装”成单个可枚举序列
public static async IAsyncEnumerable<user> GetAllUsersAsync(HttpClient client)</user>
内部用while (hasNext)+await client.GetAsync(...)+yield return，调用方仍可用同步风格await foreach
源码里最容易被忽略的点
不是语法，而是生命周期和调试行为：
- 迭代器方法体**不会在声明时执行**，只在第一次调用
GetEnumerator()（比如foreach开始）才进入，且每次MoveNext()才执行到下一个yield return - VS 调试时无法在
yield return行设断点并“单步进入”下一次迭代——它跳转的是状态机自动生成的 MoveNext 方法，不是原代码行 - 如果迭代器中抛出异常，异常栈追踪显示的是状态机类名（如
<getallusersasync>d__3</getallusersasync>），不是原始方法名；开启“仅我的代码”可缓解，但日志中仍需注意
真要调试逻辑，建议把核心计算提取到独立方法，yield return 只做“转发”。
