EF Core编译查询仅在高频、固定结构、仅参数变化的场景下有效；同步用EF.CompileQuery，异步必须用EF.CompileAsyncQuery；需显式声明所有参数，不支持闭包、运行时值、IQueryable返回及低频查询。
EF Core 编译查询不是“开了就快”，而是必须在高频、固定结构、仅参数变化的查询场景下才值得用；否则反而增加内存开销和代码复杂度。
EF.CompileQuery 和 EF.CompileAsyncQuery 怎么选
同步查询用 EF.CompileQuery，异步操作必须用 EF.CompileAsyncQuery —— 两者不能混用，类型签名不兼容。比如你写了个 Func<DbContext, int, Product> 去喂 EF.CompileAsyncQuery，编译直接报错：CS1660: Cannot convert lambda expression to type 'Func<...>' because it is not a delegate type'。
-
EF.CompileQuery返回的是Func<DbContext, TParam, TResult>，调用时直接传上下文和参数 -
EF.CompileAsyncQuery返回的是Func<DbContext, TParam, ValueTask<TResult>>，必须 await 调用 - 若查询本身不涉及 I/O（如内存数据库测试），用同步版更轻量；但生产环境几乎都该用异步版，避免线程池饥饿
编译查询必须是静态委托，不能捕获局部变量
常见错误是把 userId 或 status 写成闭包变量：
var status = OrderStatus.Processing; var compiled = EF.CompileQuery((AppDbContext ctx) => ctx.Orders.FirstOrDefault(o => o.Status == status));
这会导致编译失败或运行时报 InvalidOperationException: The parameter 'status' was not bound in the query。编译查询只接受显式参数，所有可变条件必须声明为委托签名的一部分：
- ✅ 正确写法：
(AppDbContext ctx, OrderStatus status) => ctx.Orders.FirstOrDefault(o => o.Status == status) - ❌ 错误写法：在 lambda 外定义变量并直接引用
- 编译查询无法识别
DateTime.Now、Guid.NewGuid()等运行时值，它们必须作为参数传入
编译查询不支持返回集合类型（IQueryable / IEnumerable）
EF.CompileQuery 只接受返回单个实体、值类型或 DTO 的表达式，比如 Product、int、OrderSummary。如果你写：
EF.CompileQuery((AppDbContext ctx) => ctx.Orders.Where(o => o.CreatedAt > DateTime.Today))
会编译失败，提示：CS8370: Feature 'target-typed new' is not available in C# 9.0（实际是底层不支持 IQueryable 编译）。它只支持“终结操作符”结尾的查询：
- ✅ 支持：
First、FirstOrDefault、Single、SingleOrDefault、Count、Any、Sum等 - ❌ 不支持：
Where、Select、OrderBy单独使用（无终结符） - 想查多条？得用
ToList或ToArray，但注意：EF Core 7+ 才支持EF.CompileQuery(... => ... .ToList())；EF Core 6 及以前不支持
性能收益有门槛，别在低频查询上浪费精力
编译查询节省的是“表达式树解析 + SQL 生成”阶段的开销，这部分在单次查询中通常只有几十微秒。实测数据表明：
- 查询执行频率低于 100 次/秒，基本看不出差异
- 万次调用级别，同步编译查询比普通 LINQ 快约 2 倍；十万次以上，优势扩大到 4–6 倍
- 但若查询本身含
Include多级关联，或结果集巨大，编译带来的收益会被 IO 和内存分配吞没 - 真正容易被忽略的是：编译后的委托是静态生命周期，长期驻留内存 —— 如果你为每个租户动态生成不同查询（比如拼接不同表名），会引发内存泄漏
