EF Core 实现原理

┌─────────────────────────────────────────────┐
│ 你的代码：DbContext / LINQ / SaveChanges     │  ← 门面层（Facade）
├─────────────────────────────────────────────┤
│ 查询管线 & 保存管线（QueryCompiler /          │  ← 核心层（与数据库无关）
│ ChangeTracker / IdentityMap）               │
├─────────────────────────────────────────────┤
│ 关系型抽象层（EFCore.Relational）：            │  ← 关系层（SQL 方言无关）
│ SQL 表达式树、Migration 模型差异、命令批处理     │
├─────────────────────────────────────────────┤
│ Provider 插件（Npgsql / SqlServer / MySql）  │  ← 方言层（可替换）
│ SQL 生成器、类型映射、DDL 翻译器               │
└─────────────────────────────────────────────┘

var orders = db.Orders
    .Where(o => o.Price > 100)
    .OrderByDescending(o => o.CreatedAt)
    .Take(20)
    .ToList();

① IQueryable 阶段
   db.Orders.Where(...) 只是往表达式树（Expression Tree）上挂节点，
   没有访问数据库，没有枚举任何数据。

② 编译阶段（QueryCompiler.Compile）
   遇到终结符（ToList / FirstOrDefault / Count...）才真正开始。
   表达式树被编译成一个委托，首次编译的结果会被缓存——
   所以同一个 LINQ 查询第二次执行会快得多。

③ 翻译阶段（逐方法翻译器）
   内置 200+ 个翻译器：Where→WHERE，OrderBy→ORDER BY，
   Take→LIMIT/TOP……每个 LINQ 方法各自对应一个翻译规则。
   翻译不了的直接抛 InvalidOperationException。

④ 方言生成（Provider 的 QuerySqlGenerator）
   抽象 SQL 表达式 → 具体方言：
   - SQL Server: SELECT TOP (20) ...
   - PostgreSQL: SELECT ... LIMIT 20

⑤ 执行与物化（Materializer）
   IDataReader 逐行读取 → 按"塑形（Shaping）"规则拼成对象图。
   Include 不是 JOIN 完再拼装，而是在 reader 层面按层级物化。

① 发现变更（DetectChanges）
   默认在 SaveChanges 时自动触发。
   方式 A【快照比对】：Add/Attach 时为每个实体存一份原始值副本，
      保存时逐属性 Diff——简单粗暴，内存开销 O(实体数 × 属性数)。
   方式 B【变更代理】：动态生成实体子类，属性 setter 里埋钩子，
      赋值瞬间自动标脏——零比对开销，但要求实体属性必须是 virtual。

② 状态打标
   每个实体被打上 Added / Modified / Deleted / Unchanged 之一。

③ 拓扑排序
   按外键依赖排执行顺序：先插主表行，再插子表行；
   删除则相反。这保证约束不会在执行中途被破坏。

④ 命令批处理
   同类操作合并进一批 SQL（默认一批最多 N 条命令），
   而不是每个实体一次往返。

⑤ 事务包裹
   所有命令在同一个事务里执行，中途失败整体回滚。

⑥ AcceptAllChanges
   成功后把所有实体状态重置为 Unchanged，快照刷新。
   此后 DbContext 中所有实体都是"干净"的。

// 方案 1：批量插入不走跟踪（.NET 7+）
await db.Orders.ExecuteInsertAsync(new Order { ... });   // 每个实体仍是一次往返
// 真正的大批量：干脆绕开 EF，用 Dapper 或原生 SQL 一次 INSERT 多行

// 方案 2：ExecuteUpdate / ExecuteDelete——不加载实体、不改状态机
await db.Orders
    .Where(o => o.Status == "Cancelled")
    .ExecuteDeleteAsync();   // 一条 DELETE，零实体物化

扫描 DbSet<> 与实体类
   ↓
① 约定（Conventions）先跑
   例：发现 Order.CustomerId 属性 + Customer 类型的导航属性
      → 自动推断出"CustomerId 是外键"并建立关系
   例：Id / OrderId 结尾的属性 → 自动推断为主键
   ↓
② 显式配置（Fluent API / Data Annotations）后跑，覆盖约定
   modelBuilder.Entity<Order>().HasKey(o => o.OrderNo);
   ↓
③ 产出 IModel——不可变的模型对象图，缓存复用

读取 ModelSnapshot（旧模型）
对比当前代码中的 DbContext/实体类（新模型）
→ 计算两者差异（diff）
→ 生成一组 MigrationOperation 对象
→ 写成 Up()/Down() 方法代码
→ 用新模型覆盖 ModelSnapshot