IEnumerator<out T>继承IDisposable是否为C#强制实现细节？非yield场景探讨

现有yield状态机场景下的核心原因 #

在C#迭代器的原生实现逻辑里，IEnumerator<out T>继承IDisposable的设计和yield驱动的状态机直接绑定：

状态机的设计确保迭代器正确使用时finally块会执行，这是因为IEnumerator实现了IDisposable，C#的foreach循环会调用迭代器的Dispose方法（即使是非泛型IEnumerator，若实现了IDisposable也会调用）。生成的迭代器中的IDisposable实现会根据当前状态确定相关的finally块并执行对应代码。

除此之外还有两个实用层面的考量：

• 降低foreach循环的编译器检查成本：无需额外判断迭代器是否实现IDisposable，直接统一执行Dispose逻辑即可。
• 规避手动管理的风险：foreach循环中无法直接获取迭代器对象手动调用Dispose，通过接口继承让框架自动完成资源清理，减少开发者遗漏释放操作的概率。

无yield且允许手动Dispose场景下的必要性 #

即便移除yield状态机、且foreach支持手动调用Dispose，IEnumerator<out T>继承IDisposable依然有不可替代的价值：

• 统一资源清理契约：迭代器本质是遍历状态的持有者，部分自定义迭代器可能持有非托管资源（如文件句柄、数据库连接），继承IDisposable能为所有迭代器定义统一的资源清理规范，让开发者明确所有迭代器都需要被妥善释放。
• 兼容性与一致性：保持和现有代码生态的兼容，避免接口变更导致大量旧代码需要修改；同时让泛型与非泛型迭代器的行为保持一致，降低学习和维护成本。
• 强制规范实现：通过接口继承的方式，强制自定义迭代器的开发者考虑资源清理逻辑，避免复杂遍历场景中因遗漏释放操作导致的资源泄漏问题。
• 简化框架级处理：对于框架或类库来说，统一的接口让遍历相关的工具方法（如LINQ扩展）无需额外判断，就能安全处理所有迭代器的资源释放，提升代码健壮性和可维护性。

内容的提问来源于stack exchange，提问作者Ivan Petrov