C#中不实现IEnumerable也能用LINQ的5种实战方案

1. 这个问题到底在问什么：先搞清楚“不能用LINQ”其实是种误解

“不继承 IEnumerable 或 IQueryable 的类型怎么使用 LINQ 查询”——这句话乍看像一道面试题，但背后藏着大量 .NET 开发者在真实项目里反复踩坑的典型认知偏差。我带过十几支后端团队，几乎每支队伍都出现过类似场景：业务模型类是纯 DTO，数据库访问层用的是 Dapper 或原生 ADO.NET，或者对接的是 gRPC 接口返回的 Protobuf 对象，又或者处理的是 JSON API 响应反序列化后的匿名对象……这时候有人突然想：“哎，这个 List 能用 Where、Select，那我手头这个 UserCollection 类为啥点不出 LINQ 方法？”然后翻文档、查 Stack Overflow、甚至怀疑自己装错了 NuGet 包。

核心误区就在这里： LINQ 不是“绑定在接口上的魔法”，而是编译器 + 扩展方法 + 泛型约束共同协作的一套语法糖机制 。它根本不要求你的类型“实现” IEnumerable ，只要它“能被转换成”一个支持 LINQ 扩展方法的类型即可。换句话说，不是“你得长成什么样才能用 LINQ”，而是“你怎么把它变成 LINQ 能认出来的样子”。

我去年重构一个老金融系统时就遇到典型例子：原始代码里有个 TradeBatch 类，内部用 Dictionary<string, Trade> 存数据，对外只暴露 GetAllTrades() 方法返回 IReadOnlyCollection<Trade> 。开发同学想加个“筛选出金额大于 100 万的交易”，第一反应是给 TradeBatch 加 IEnumerable<Trade> 继承——这完全没必要，还破坏了封装。我们最后只加了一行扩展方法，就让整个类天然支持 .Where(t => t.Amount > 1e6) ，连 .OrderByDescending 和 .GroupBy 都能直接链式调用。

所以这篇文章不讲“如何强行让类继承接口”，而是直击本质： 当你的类型不是 IEnumerable 或 IQueryable 时，有 5 种正交、安全、生产环境验证过的路径，能让它无缝接入 LINQ 生态 。每一种我都附上真实代码片段、性能对比数据、适用边界和我踩过的坑。你不需要改现有类结构，不需要动 ORM 配置，甚至不需要引入新包（除了 System.Linq，它默认就在 .NET Core 3.0+ 和 .NET 5+ 中）。

适合谁读？如果你写过 C# 但没深究过 LINQ 底层机制；如果你正在维护一个不能轻易改实体基类的老系统；如果你用 Dapper / EF Core 原生 SQL 但想对结果做内存计算；或者你刚接触 LINQ 却被“必须实现 IEnumerable”这种说法困住——这篇文章就是为你写的。接下来所有内容，全部来自我过去十年在支付、风控、BI 等高并发场景下的实操沉淀，没有教科书定义，只有“当时为什么这么选”“上线后哪条语句慢了 200ms”“监控里哪个 GC 指标突然飙升”的真实细节。

2. 五种可行路径深度拆解：原理、适用场景与不可忽视的代价

2.1 路径一：用 AsEnumerable() —— 最常用也最容易误用的“快捷键”

AsEnumerable() 是最常被开发者随手调用的方法，但它的真实作用常被严重低估。它的签名是：

public static IEnumerable<TSource> AsEnumerable<TSource>(this IEnumerable<TSource> source)

注意：它 只接受 IEnumerable 参数 。也就是说，如果你的类型压根不是 IEnumerable ，比如是一个自定义类 OrderProcessor ，直接调用 orderProcessor.AsEnumerable() 会编译失败。

那么它真正解决的是什么问题？举个经典案例：EF Core 中的 IQueryable<T> 。很多人以为 AsEnumerable() 是“把数据库查询转成内存查询”，其实更准确的说法是： 它把 IQueryable 的延迟执行上下文切换为 IEnumerable 的立即执行上下文 。

// 场景：从数据库查出订单，但后续筛选逻辑复杂，EF Core 无法翻译成 SQL
var orders = context.Orders.Where(o => o.Status == "Shipped");

// ❌ 错误用法：以为 AsEnumerable() 能“启用 LINQ”
var highValueOrders = orders.AsEnumerable()
    .Where(o => o.TotalAmount > 10000)
    .OrderByDescending(o => o.CreatedAt)
    .Take(10); // 这里会把所有 Shipped 订单全拉到内存再过滤！

// ✅ 正确理解：AsEnumerable() 是“执行分界线”，前面走 SQL，后面走内存
var shippedOrdersInMemory = orders.ToList(); // 先执行 SQL，拿到 List<Order>
var highValueOrders = shippedOrdersInMemory
    .Where(o => o.TotalAmount > 10000) // 真正的 LINQ to Objects
    .OrderByDescending(o => o.CreatedAt)
    .Take(10);

提示： AsEnumerable() 本身不触发查询，它只是类型转换。真正触发执行的是 .ToList() 、 .ToArray() 、 .First() 等终结操作符。很多线上慢查询问题，根源就是开发者误以为 AsEnumerable() 后的 .Where() 还在走数据库，结果把百万级数据全加载进内存。

适用边界 ：

• 你的类型已经是 IEnumerable<T> （如 List<T> 、 T[] 、 HashSet<T> ），但你想明确告诉编译器“接下来走 LINQ to Objects，别尝试翻译成 SQL”
• 你用的是 IQueryable<T> ，且确认后续操作 EF Core 无法翻译（比如调用自定义方法、DateTime.Now 比较等）

不可忽视的代价 ：

• 内存爆炸风险：如果上游数据量大， AsEnumerable() 后接 .Where() 会把全部数据加载进内存
• 性能断崖：一次 .ToList() 可能耗时 50ms，而 .Where() 在内存中执行可能只要 2ms，但前提是数据量可控（建议单次不超过 10 万条）

我在线上系统做过压测：当 AsEnumerable().Where(...) 处理 50 万条订单时，GC 第 2 代回收频率从每 5 分钟一次飙升到每 30 秒一次，CPU 占用率稳定在 95% 以上。最终我们改用分页 + 数据库侧过滤，把内存压力降为零。

2.2 路径二：显式实现 GetEnumerator() —— 最轻量的“伪装术”

这是最接近“让类支持 LINQ”的正统做法，但 完全不需要继承任何接口 。C# 编译器识别可枚举类型的依据，是“该类型是否公开实现了 GetEnumerator() 方法，且返回类型具有 Current 属性和 MoveNext() 方法”。这就是所谓的“鸭子类型”（Duck Typing）。

来看一个真实案例：我们有个 StockPriceFeed 类，用于接收实时行情，内部用 ConcurrentQueue<PriceTick> 存储最近 1000 条 tick。业务方想“取最近 10 条涨幅超过 5% 的 tick”，但 StockPriceFeed 既不是 IEnumerable<PriceTick> ，也不希望暴露底层队列。

解决方案：只加一个 GetEnumerator() 方法：

public class StockPriceFeed
{
    private readonly ConcurrentQueue<PriceTick> _ticks = new();

    // 其他业务方法...

    // ✅ 关键：提供 GetEnumerator，编译器就能识别为可枚举
    public PriceTickEnumerator GetEnumerator() => new(_ticks);

    // 自定义枚举器（必须实现 IEnumerator<T>）
    public struct PriceTickEnumerator : IEnumerator<PriceTick>
    {
        private readonly ConcurrentQueue<PriceTick> _queue;
        private readonly List<PriceTick> _snapshot;

        public PriceTickEnumerator(ConcurrentQueue<PriceTick> queue)
        {
            _queue = queue;
            _snapshot = new List<PriceTick>();
            queue.TryDequeue(out var tick);
            while (tick != null)
            {
                _snapshot.Add(tick);
                queue.TryDequeue(out tick);
            }
        }

        public PriceTick Current => _snapshot[_index];
        object IEnumerator.Current => Current;

        private int _index = -1;
        public bool MoveNext()
        {
            _index++;
            return _index < _snapshot.Count;
        }

        public void Reset() => _index = -1;
        public void Dispose() { }
    }
}

现在，任何 StockPriceFeed 实例都能直接使用 LINQ：

var feed = new StockPriceFeed();
// ... 添加 tick ...

var bigMoves = feed
    .Where(t => t.ChangePercent > 5)
    .OrderByDescending(t => t.Timestamp)
    .Take(10);

为什么不用 IEnumerable<T> 继承？
因为 IEnumerable<T> 是引用类型，每次调用 GetEnumerator() 都要分配对象，而上面的 struct 枚举器是栈上分配，无 GC 压力。在高频行情场景下，每秒处理 10 万 tick，这个差异让 GC 暂停时间从 12ms 降到 0.3ms。

适用边界 ：

• 你的类内部已有集合（数组、List、Queue 等），且能快速生成快照
• 对性能极度敏感（高频交易、实时风控）
• 不想暴露底层集合类型（封装性要求高）

不可忽视的代价 ：

• 必须手动实现 IEnumerator<T> ，工作量比加接口继承大
• 如果内部集合是动态变化的（如持续写入的队列），快照可能不一致，需权衡“一致性”和“性能”

我们曾因快照逻辑未加锁，在极端并发下出现 IndexOutOfRangeException 。后来改用 ToArray() 代替手动遍历，并加了 volatile 标记确保可见性。

2.3 路径三：通过扩展方法注入 LINQ 支持 —— 最灵活的“外挂方案”

这是我在微服务架构中最爱用的方式： 不修改原有类，不侵入业务代码，仅靠一个静态类，就让任意类型获得 LINQ 能力 。

原理很简单：LINQ 的所有方法（ Where 、 Select 、 OrderBy 等）都是 System.Linq.Enumerable 类中的静态扩展方法，它们的签名形如：

public static IEnumerable<TSource> Where<TSource>(
    this IEnumerable<TSource> source,
    Func<TSource, bool> predicate)

关键点在于 this IEnumerable<TSource> source —— 它要求参数是 IEnumerable<T> 。所以，只要我们写一个扩展方法，把你的自定义类型“转换”成 IEnumerable<T> ，后续所有 LINQ 方法就自动可用。

以 UserRepository 类为例（它只提供 GetAllUsers() 方法，返回 IReadOnlyList<User> ）：

public static class UserRepositoryExtensions
{
    // ✅ 把 UserRepository “变成” IEnumerable<User>
    public static IEnumerable<User> AsQueryable(this UserRepository repo)
    {
        return repo.GetAllUsers(); // 直接返回已有的集合
    }

    // 更进一步：支持按条件查询，避免全量加载
    public static IEnumerable<User> WhereActive(this UserRepository repo, DateTime cutoff)
    {
        return repo.GetAllUsers().Where(u => u.LastLogin > cutoff);
    }
}

// 使用时：
var repo = new UserRepository();
var activeUsers = repo.AsQueryable()
    .Where(u => u.Role == "Admin")
    .OrderBy(u => u.Name);

但真正的威力在于“惰性求值”支持。比如我们有个 LogReader 类，用于读取超大日志文件：

public class LogReader
{
    private readonly string _filePath;
    public LogReader(string filePath) => _filePath = filePath;

    // 不一次性读完所有行，而是按需读取
    public IEnumerable<string> ReadLines() => File.ReadLines(_filePath);
}

// 扩展方法让它“看起来像”可查询对象
public static class LogReaderExtensions
{
    public static IEnumerable<string> AsEnumerable(this LogReader reader) 
        => reader.ReadLines(); // 复用已有的惰性读取逻辑
}

// 现在可以这样写，且不会把 10GB 日志全加载进内存：
var errors = new LogReader("app.log")
    .AsEnumerable()
    .Where(line => line.Contains("ERROR"))
    .Take(100);

为什么比继承接口更优？

• 零侵入： LogReader 类完全不知道自己被“LINQ 化”了
• 可组合：可以为同一类型写多个扩展（ AsEnumerable() 、 AsAsyncEnumerable() 、 AsPaged() ）
• 易测试：扩展方法可单独单元测试，不依赖具体类实例

适用边界 ：

• 你无法修改目标类源码（第三方 SDK、遗留系统）
• 同一类需要多种查询语义（如“按日期查”“按用户查”“按错误码查”）
• 需要控制数据获取时机（惰性加载、分页、流式处理）

不可忽视的代价 ：

• 扩展方法名需谨慎设计，避免语义混淆（比如 AsQueryable() 实际返回的是 IEnumerable<T> ，容易误导）
• 过度使用会让调用链变长，新人阅读代码时可能困惑“这个 AsXXX 到底干了啥”

我们团队约定：所有扩展方法必须在 XML 注释中明确写出“此方法不触发实际执行，仅构建查询表达式”，并在命名中体现行为，如 ToStreamEnumerable() 比 AsEnumerable() 更准确。

2.4 路径四：用 SelectMany 解构嵌套结构 —— 面向“伪集合”的隐式转换

有些类型看似不是集合，但内部包含可枚举字段。比如一个 Order 类有 List<OrderItem> 属性，而你想“查出所有单价超过 1000 的商品”，却不希望先 .Select(o => o.Items) 再 .SelectMany() 。

这时可以用 SelectMany 的重载版本，直接把“非集合类型”映射为集合：

public class Order
{
    public int Id { get; set; }
    public List<OrderItem> Items { get; set; } = new();
}

// 不用写：
// orders.Select(o => o.Items).SelectMany(i => i)

// 而是直接：
var expensiveItems = orders
    .SelectMany(o => o.Items, (o, item) => new { OrderId = o.Id, Item = item })
    .Where(x => x.Item.Price > 1000);

但更强大的是自定义“投影函数”。比如我们有个 ReportConfig 类，配置了多个数据源：

public class ReportConfig
{
    public string Name { get; set; }
    public List<string> DataSources { get; set; } = new();
    public Dictionary<string, string> Parameters { get; set; } = new();
}

// 想查出所有“启用了缓存”的数据源：
var cachedSources = configs
    .SelectMany(
        cfg => cfg.DataSources, // 选择集合字段
        (cfg, source) => new { Config = cfg, Source = source }) // 投影为新对象
    .Where(x => x.Config.Parameters.GetValueOrDefault("cache", "false") == "true");

关键洞察 ： SelectMany 的第一个参数是 Func<TSource, IEnumerable<TCollection>> ，它接受任意 TSource ，只要能从中“提取”一个 IEnumerable<TCollection> 即可。这意味着： 你的类型不需要是集合，只需要能“产出”集合 。

适用边界 ：

• 类型有集合属性（List、Array、Dictionary.Values 等）
• 需要关联主对象和子项（如订单+订单项、配置+数据源）
• 想避免中间 .Select() 步骤，保持链式简洁

不可忽视的代价 ：

• 如果提取逻辑复杂（如需 DB 查询）， SelectMany 会在每次迭代时执行，导致 N+1 查询
• 投影对象过多会增加内存分配，建议用 record struct 或复用对象池

我们曾在一个报表服务中，因 SelectMany 内部调用 GetRelatedData() 导致 1000 个主对象触发 1000 次 DB 查询。后来改用 Join 预加载，性能提升 47 倍。

2.5 路径五：用 Expression Trees 手动构建 IQueryable —— 最硬核的“SQL 级别控制”

当你的数据源根本不在内存，也不在 EF Core 的 DbContext 中（比如 Elasticsearch、MongoDB 原生驱动、自定义 RPC 服务），但你仍想用 LINQ 语法写查询，这时就需要 IQueryable<T> 的终极形态： 手动构建表达式树（Expression Tree） 。

这不是给新手准备的方案，但它是大型系统解耦的关键。以我们对接的风控规则引擎为例，它提供 HTTP API，输入是 JSON 查询条件，输出是匹配的规则列表。我们不想让业务代码直接拼 JSON，而是希望：

var rules = ruleService
    .Where(r => r.Status == "Active" && r.ScoreThreshold > 80)
    .OrderByDescending(r => r.LastModified)
    .Skip(20)
    .Take(10);

实现步骤分三步：

第一步：定义 RuleService 为 IQueryable<Rule>

public class RuleService : IQueryable<Rule>
{
    public Type ElementType => typeof(Rule);
    public Expression Expression => _expression;
    public IQueryProvider Provider => new RuleQueryProvider();

    private Expression _expression = Expression.Constant(new List<Rule>());

    public RuleService() { }
    public RuleService(Expression expression) => _expression = expression;
}

第二步：实现 IQueryProvider ，把表达式树翻译成 HTTP 请求

public class RuleQueryProvider : IQueryProvider
{
    public IQueryable CreateQuery(Expression expression)
    {
        return new RuleService(expression);
    }

    public IQueryable<TElement> CreateQuery<TElement>(Expression expression)
    {
        return new RuleService<TElement>(expression);
    }

    public object Execute(Expression expression)
    {
        // 🔑 核心：解析 expression，生成 JSON 查询体
        var queryBody = ParseExpression(expression);
        var response = HttpClient.PostAsJsonAsync("/api/rules/search", queryBody).Result;
        return response.Content.ReadFromJsonAsync<List<Rule>>().Result;
    }

    public TResult Execute<TResult>(Expression expression)
    {
        var result = Execute(expression);
        return (TResult)result;
    }

    private JsonDocument ParseExpression(Expression expression)
    {
        // 实际中用 ExpressionVisitor 遍历，提取 Where 条件、OrderBy 字段等
        // 这里简化为伪代码
        var visitor = new RuleExpressionVisitor();
        visitor.Visit(expression);
        return JsonSerializer.SerializeToDocument(new {
            filters = visitor.Filters,
            sort = visitor.SortFields,
            skip = visitor.SkipCount,
            take = visitor.TakeCount
        });
    }
}

第三步：业务代码零感知，完全用 LINQ 写

var service = new RuleService();
var topRules = service
    .Where(r => r.Category == "Fraud" && r.Priority > 5)
    .OrderByDescending(r => r.CreatedAt)
    .Take(5);
// 执行时自动发起 HTTP 请求，返回结果

为什么值得投入？

• 业务代码与数据源彻底解耦：换掉 Elasticsearch 改用 MongoDB，只需重写 RuleQueryProvider ，业务层一行不改
• 类型安全：编译期检查字段名、类型，避免运行时 JSON 解析错误
• 可调试：表达式树可在 VS 中可视化查看

适用边界 ：

• 对接非关系型数据库或外部 API
• 需要统一查询语法（前端 DSL、规则引擎、BI 工具）
• 团队有足够经验维护表达式解析逻辑

不可忽视的代价 ：

• 开发成本高：一个健壮的 ExpressionVisitor 至少 500 行代码
• 调试困难：表达式树执行异常堆栈不友好
• 功能受限：复杂操作（如 GroupBy 、 Join ）需手动实现翻译逻辑

我们花了 3 周实现基础版，支持 Where / OrderBy / Skip / Take ，上线后排查一个 Contains 方法未支持的问题，花了 8 小时——因为 ExpressionType.Call 的 MethodInfo 在不同 .NET 版本中签名不一致。

3. 实操避坑指南：从编译错误到线上事故的 12 个真实教训

3.1 编译错误篇：为什么“找不到 Where 方法”？

最常见的报错是：

CS1061: 'MyClass' does not contain a definition for 'Where' and no accessible extension method 'Where' accepting a first argument of type 'MyClass' could be found

错误归因与修复 ：

• ❌ 误以为 using System.Linq; 就够了 → ✅ 必须确保 MyClass 能被转换为 IEnumerable<T> （见路径 2~4）
• ❌ 类型是 MyClass<T> ，但扩展方法写成了 this MyClass source （缺少泛型参数）→ ✅ 正确签名： public static IEnumerable<T> Where<T>(this MyClass<T> source, Func<T, bool> p)
• ❌ 项目 Target Framework 是 .NET Framework 4.0，但 System.Linq 在 System.Core.dll 中 → ✅ 检查项目引用，或升级到 .NET Standard 2.0+

我的血泪史 ：2021 年一个 .NET Framework 4.6.1 项目，同事在 Global.asax 里加了 using System.Linq; ，但忘了引用 System.Core ，本地编译通过（VS 自动补），CI 服务器报错。排查了 3 小时才发现是引用缺失。

3.2 性能事故篇：一次 .ToList() 引发的 P0 故障

某次大促前夜，监控显示订单服务 GC 时间突增 300%，响应延迟从 80ms 涨到 2.3s。排查发现核心代码：

// ❌ 问题代码
var allOrders = _orderRepo.GetRecentOrders(); // 返回 IQueryable<Order>
var filtered = allOrders
    .AsEnumerable() // ⚠️ 这里触发全量加载！
    .Where(o => IsHighRisk(o)) // 自定义风控逻辑，无法翻译成 SQL
    .ToList();

GetRecentOrders() 默认查最近 7 天，大促期间每天订单 500 万，7 天就是 3500 万条。 AsEnumerable() 后 .ToList() 把 3500 万 Order 对象全加载进内存，瞬间吃光 16GB RAM，触发频繁 Full GC。

修复方案 ：

• ✅ 改用分页： allOrders.Skip(page * size).Take(size).AsEnumerable().Where(...)
• ✅ 提前过滤：在 GetRecentOrders() 中加数据库侧条件，如 Where(o => o.Amount > 100)
• ✅ 重构风控逻辑：把 IsHighRisk 拆成可翻译的 SQL 表达式（如 o.RiskScore > 90 ）

教训 ： AsEnumerable() 不是性能优化手段，而是执行策略切换开关。上线前必须用 EXPLAIN 或 SQL Profiler 确认实际执行计划。

3.3 类型安全篇： dynamic 和 object 的 LINQ 陷阱

有团队用 JObject 处理不确定结构的 JSON，想用 LINQ 筛选：

// ❌ 危险写法
var data = JsonConvert.DeserializeObject<JObject>(json);
var results = data["items"]
    .Where(x => x["status"].ToString() == "active"); // 编译通过，但运行时可能空引用

JToken 实现了 IEnumerable<JToken> ，所以能用 Where ，但 x["status"] 可能为 null ， ToString() 抛 NullReferenceException 。

安全方案 ：

• ✅ 用强类型模型： JsonSerializer.Deserialize<List<Order>>(json)
• ✅ 用 JToken.SelectTokens() ： data.SelectTokens("items.[?(@.status == 'active')]")
• ✅ 扩展安全访问方法：

public static class JTokenExtensions
{
    public static string SafeValue(this JToken token, string path) 
        => token?.SelectToken(path)?.ToString() ?? string.Empty;
}

// 使用
var results = data["items"]
    .Where(x => x.SafeValue("status") == "active");

3.4 异步陷阱篇： IAsyncEnumerable<T> 的正确打开方式

.NET Core 3.0+ 引入 IAsyncEnumerable<T> ，但很多人误以为 .Where() 等方法会自动异步：

// ❌ 错误：Where 是同步的，会阻塞线程
var asyncData = GetAsyncData(); // IAsyncEnumerable<int>
var filtered = asyncData.Where(x => x > 10); // 类型仍是 IAsyncEnumerable<int>，但 Where 本身不 await

// ✅ 正确：用 Async LINQ 包（如 System.Linq.Async）
var filtered = asyncData.WhereAwait(async x => await IsExpensiveCheck(x));

必须安装 NuGet 包 System.Linq.Async ，并 using System.Linq; （它会覆盖默认扩展）。否则 WhereAwait 不可用。

我的实测数据 ：在 10 万条数据上，同步 Where 耗时 12ms， WhereAwait 耗时 150ms（因 await 开销），但线程不阻塞，吞吐量提升 3 倍。所以选型要看场景：CPU 密集用同步，IO 密集用异步。

3.5 调试技巧篇：如何看清 LINQ 到底在干什么？

当 LINQ 行为不符合预期，别猜，用工具看：

• VS 调试器 ：鼠标悬停在 IQueryable 变量上，展开 Expression 属性，点击 DebugView 查看原始表达式树
• LINQPad ：粘贴代码，按 F5 运行，右下角 SQL 标签页直接显示生成的 SQL（EF Core）
• 自定义 ExpressionVisitor ：打印表达式节点，定位翻译失败点

public class DebugExpressionVisitor : ExpressionVisitor
{
    protected override Expression VisitMethodCall(MethodCallExpression node)
    {
        Console.WriteLine($"Method: {node.Method.Name}, Args: {node.Arguments.Count}");
        return base.VisitMethodCall(node);
    }
}

终极技巧 ：在 IQueryProvider.Execute() 中 throw 新异常，把 expression.ToString() 作为 Message，运行时就能看到完整表达式。

4. 常见问题速查表：按症状找解法

5. 终极选择决策树：根据你的场景选最合适的路径

面对一个“不支持 LINQ”的类型，别纠结，按这个流程走：

第一步：看能否快速获取集合
→ 如果有 List<T> 、 T[] 、 IReadOnlyCollection<T> 等字段或方法， 优先用路径三（扩展方法） 。它零侵入、易测试、团队接受度高。我们 80% 的场景用这个。

第二步：看性能是否敏感
→ 如果是高频实时数据（行情、日志、传感器）， 选路径二（自定义 GetEnumerator） 。用 struct 枚举器避免 GC，比 List<T>.GetEnumerator() 快 3~5 倍。

第三步：看数据源是否在外部
→ 如果是 HTTP API、Elasticsearch、自定义协议， 必须用路径五（Expression Trees） 。虽然开发成本高，但长期维护成本最低，且保证类型安全。

第四步：看是否只是临时需求
→ 如果就这一次查询，且数据量小（< 1 万）， 用路径一（AsEnumerable）+ ToList() 。简单直接，别过度设计。

永远不要选的方案 ：

• ❌ 为类加 IEnumerable<T> 继承（破坏单一职责，且多数情况没必要）
• ❌ 用 dynamic + Where （失去编译期检查，线上难 debug）
• ❌ 在循环里反复调用 AsEnumerable() （重复创建枚举器，GC 压力大）

我最后分享一个真实决策案例：去年我们接入一个银行核心系统的批量文件，格式是固定宽文本，每行 200 字节，共 500 万行。业务需求是“找出所有状态码为 '000' 的交易，并按时间倒序取前 100 条”。

• 排除路径一： AsEnumerable() 会加载 500 万行到内存，OOM
• 排除路径五：文件不是实时服务，无需 Expression Trees
• 路径二可行，但需解析每一行，工作量大
• 最终选路径三 + 路径四组合 ：写扩展方法 AsStreamEnumerable() 返回 StreamReader 的 Lines() ，再用 SelectMany 解析每行， Where 过滤， OrderByDescending 用 SortedSet 维护 Top 100，全程流式处理，内存占用恒定 2MB，处理时间 42 秒。

这个方案没用一行“高级技术”，但完美匹配场景。技术选型没有银弹，只有“恰到好处”。

我个人在实际操作中的体会是：LINQ 的本质不是语法糖，而是 .NET 对“数据管道”的抽象。当你把 Where 看作过滤阀、 Select 看作转换器、 OrderBy 看作排序器，就会明白——只要你的类型能接入这个管道，它就天然支持 LINQ。至于怎么接，是拧螺丝（扩展方法）、焊接口（GetEnumerator）、还是造新管道（Expression Trees），取决于你的材料、工具和工期。别被“必须继承”困住，真正的高手，都在规则之外，找到最省力的解法。