EF Core 编译模型 / 模型裁剪：冷启动与查询优化

EF Core 编译模型 / 模型裁剪：冷启动与查询优化 🚀

适配 .NET 8/9 与 ABP vNext。交付：一键启用脚本、可复现基准、N+1 审计拦截器、预热 SOP、回滚开关。
关键词：dotnet ef dbcontext optimize、UseModel(IModel)、--precompile-queries、DbCommandInterceptor、Warm-up

1. 背景与目标 🎯

EF Core 在首次使用某个 DbContext 类型（如首次查询或首次保存）时会构建元模型（实体/关系/约束/转换等）。在上百/上千实体的大模型或云原生冷启动场景，这一步会显著抬高首条查询延迟。
Compiled Models：将模型预生成为源码并编译，运行时直接加载，明显缩短首启/首查成本；EF Core 9 另有预编译查询（实验），进一步削减查询编译开销（建议灰度启用并可回滚）。

模型构建与编译模型对比

2. 概念速览与硬性限制 ⚠️

• Compiled Models（编译模型）
  通过 dotnet ef dbcontext optimize 生成模型代码；运行时调用 DbContextOptionsBuilder.UseModel(IModel) 后，EF Core 不会再执行 OnModelCreating（但生成编译模型的 CLI 过程仍会跑一次 OnModelCreating 产出代码）。
• EF9 自动发现（可选）
  当 DbContext 与编译模型在同一程序集，EF9 可自动发现编译模型；也可显式 .UseModel(...) 覆盖。

硬性限制（启用前必须满足） 🧱

1. ❌ 不支持全局查询过滤器（HasQueryFilter(...)，常用于多租户/软删）；
2. ❌ 不支持 lazy-loading 或 change-tracking 代理；
3. ❌ 不支持自定义 IModelCacheKeyFactory（如需变体，请编译多套模型并在启动时选择）；
4. 🔁 模型变更后需手动再生成编译模型。

设计提醒：若你依赖全局查询过滤器，请不要启用编译模型；或迁移为查询层注入条件、数据库视图/RLS 等替代手段后再考虑编译模型。

是否应启用编译模型 🧭