昂贵的IEnumerable：如何在不强制立即枚举的前提下避免多次枚举？

你的需求非常明确：既要延迟执行昂贵的排序操作，又要防止下游多次枚举带来的重复开销，同时还要保持IEnumerable<T>的接口兼容性——这个问题其实可以通过自定义一个轻量的包装类来完美解决，完全不需要修改下游函数的签名。

核心思路 #

我们需要一个实现IEnumerable<T>的类，内部用Lazy<List<T>>来缓存枚举结果：

• 当下游第一次枚举时，才触发昂贵的排序操作，并把结果缓存到List中
• 后续所有的枚举请求都直接返回缓存的List的枚举器，避免重复执行排序
• 要是下游根本不枚举，那么排序操作完全不会执行，满足延迟加载的要求

完整实现代码 #

public class CachedEnumerable<T> : IEnumerable<T>
{
    // 用Lazy来延迟初始化缓存列表，确保只执行一次昂贵操作
    private readonly Lazy<List<T>> _cachedItems;

    // 构造函数接收一个返回IEnumerable<T>的工厂方法
    public CachedEnumerable(Func<IEnumerable<T>> enumerableFactory)
    {
        _cachedItems = new Lazy<List<T>>(() => enumerableFactory().ToList());
    }

    public IEnumerator<T> GetEnumerator()
    {
        // 第一次调用时会触发工厂方法执行，后续直接用缓存的列表
        return _cachedItems.Value.GetEnumerator();
    }

    // 显式实现非泛型接口
    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }
}

使用方式 #

替换你原来的Lazy<List<Order>>写法，直接返回IEnumerable<Order>：

// 这里的工厂方法只会在第一次枚举时执行
IEnumerable<Order> expensiveEnumerable = new CachedEnumerable<Order>(
    () => fullCatalog.OrderBy(c => Prioritize(c))
);

// 下游函数完全不需要修改，直接调用即可
MaybeFullFillSomeOrders(expensiveEnumerable);

为什么这个方案更优？ #

1. 完全兼容原有接口：下游函数MaybeFullFillSomeOrders不需要任何改动，依然接收IEnumerable<Order>，完美解决了你之前需要修改所有下游接口的问题。
2. 严格延迟执行：只有当下游第一次遍历枚举时，才会执行OrderBy排序；如果下游直接返回不遍历，排序操作完全不会触发，没有任何性能开销。
3. 防止多次枚举开销：不管下游遍历多少次，排序操作只会执行一次，后续都用缓存的List，彻底避免了重复执行昂贵操作的风险。
4. 内存效率合理：虽然会把结果缓存成List，但这是避免多次执行昂贵枚举的必要代价——毕竟IEnumerable<T>本身是无状态的延迟序列，要复用结果就必须把元素存储起来。对于你提到的由多个小分区SelectMany构建的序列，ToList()会把这些分区的元素合并成一个连续列表，这已经是比较高效的缓存方式了，没有更优的替代方案（除非你能接受只枚举一次，但下游逻辑不允许的话，缓存是唯一选择）。

可选优化：添加语法糖 #

为了让使用更简洁，可以写一个静态扩展方法：

public static class EnumerableCacheExtensions
{
    public static IEnumerable<T> Cache<T>(this Func<IEnumerable<T>> enumerableFactory)
    {
        return new CachedEnumerable<T>(enumerableFactory);
    }
}

这样使用时会更优雅：

IEnumerable<Order> expensiveEnumerable = (() => fullCatalog.OrderBy(c => Prioritize(c))).Cache();

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