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()），导致整棵树被拉到内存再过滤——这种问题比缓存失效更隐蔽也更伤性能。
