EF Core 6+ 默认缓存 LINQ 查询编译结果，复用表达式骨架而非参数值；手动预编译需用 EF.CompileQuery/CompileAsyncQuery，注意参数限制与纯查询要求；闭包捕获、字符串拼接表达式、不支持方法等导致缓存失效。
EF Core 6+ 默认已缓存编译后的 LINQ 查询
从 EF Core 6 开始，DbContext 内部自动缓存了大部分 LINQ 查询的表达式树编译结果（即 QueryCompiler 编译出的委托），无需手动干预。只要查询结构相同（参数名、类型、投影逻辑一致），后续执行会复用已编译的查询计划。
这意味着你写这样的代码：
var posts = context.Posts.Where(p => p.AuthorId == authorId).ToList();
在多次调用且 authorId 值不同时，EF Core 仍能复用同一份编译结果——它把参数值本身剥离出去，只对表达式骨架做缓存。
常见误判点：这不是 SQL 查询结果缓存，而是表达式到可执行委托的编译缓存，和内存中存查出来的 List<post></post> 完全无关。
手动预编译查询：用 EF.CompileAsyncQuery 或 EF.CompileQuery
当你有高频、固定结构的查询（比如首页 Banner 加载、用户权限检查），且想跳过每次运行时的表达式解析/验证开销，可以用 EF.CompileQuery（同步）或 EF.CompileAsyncQuery（异步）提前生成委托。
-
EF.CompileQuery返回Func<dbcontext tparam tresult></dbcontext>，首次调用时完成编译，之后纯委托调用 - 必须是“纯查询”：不能含
.AsNoTracking()等链式调用（它们需在编译后追加） - 参数只能有一个，但可以是匿名类或自定义 DTO；多参数请打包成一个对象
- 编译后委托是线程安全的，可静态缓存
示例：
private static readonly Func<AppDbContext, int, Post> GetPostById =
EF.CompileQuery((AppDbContext ctx, int id) => ctx.Posts.FirstOrDefault(p => p.Id == id));
// 使用
var post = GetPostById(context, 123);
哪些查询无法被缓存？常见失效场景
EF Core 的查询编译缓存对表达式树的“结构一致性”敏感，以下情况会导致缓存未命中或编译失败：
- 使用局部变量或闭包捕获的非 const 值（如
var minDate = DateTime.Now; ctx.Orders.Where(o => o.Created > minDate)）→ 改用参数传入 - 拼接字符串生成表达式（
Expression.Lambda手动构造）→ 不在 EF 默认缓存路径内 - 调用了不支持的 .NET 方法（如
string.IsNullOrEmpty()在服务端无对应翻译）→ 触发客户端求值，破坏缓存稳定性 - 查询中混用
AsEnumerable()/ToList()中断 IQueryable 链 → 编译器无法识别完整查询边界 - EF Core 版本降级到 5.x 及更早 → 编译缓存能力弱，且
EF.CompileQuery不存在
缓存效果验证与调试技巧
光看文档不如实测。验证是否真正复用了编译结果，可通过以下方式：
- 启用 EF Core 日志，观察是否重复出现
Compiling query...（仅首次出现才正常） - 在
DbContextOptionsBuilder中开启详细日志：.LogTo(Console.WriteLine, new[] { DbLoggerCategory.Query.Name }) - 用性能分析器（如 Visual Studio Profiler 或 dotTrace）对比两次相同查询的
Microsoft.EntityFrameworkCore.Query.QueryCompilation调用次数 - 注意：
AsNoTracking()、AsSplitQuery()等行为会生成不同编译分支，属于不同缓存项
真正影响性能的，往往不是编译缓存本身，而是没意识到 IQueryable 被意外触发执行（比如在 Select 里调用 ToString()），导致整棵树被拉到内存再过滤——这种问题比缓存失效更隐蔽也更伤性能。
