Ef-Core on Coding with Denglei

EF Core 事务实战：SaveChanges、ExecutionStrategy、Outbox 与一致性边界

Tue, 16 Jun 2026 17:04:23 +0800

“事务加上了，这可不就问了嘛”。真正到线上一跑，问题就冒出来了：

数据库提交成功了，但消息没发出去
外部调用成功了，但本地事务回滚了
SQL 重试机制打开后，一段代码被重复执行了两次
同一个请求里明明都写在一起，最终状态还是不一致

这篇文章不讲抽象理论，直接回答一个工程问题：在 EF Core 里，事务边界到底该怎么画，哪些事情能靠数据库事务兜住，哪些事情必须换一种设计。

问题背景：为什么“写成功了”不等于业务真的成功

先看一个常见场景：下单成功后，需要同时完成三件事。

写入订单表
扣减库存
发出一条订单已创建消息，通知下游做履约

很多项目最开始都会写成这样：

await using var tx = await db.Database.BeginTransactionAsync(ct);

order.Status = OrderStatus.Created;
inventory.Reserve(quantity);

await db.SaveChangesAsync(ct);
await messageBus.PublishAsync(new OrderCreated(order.Id), ct);

await tx.CommitAsync(ct);

这段代码看起来很顺，实际有三个明显风险：

SaveChangesAsync 成功后，PublishAsync 失败，数据库已经提交，但下游不知道这笔订单存在
PublishAsync 成功后，CommitAsync 失败，下游收到消息，但数据库里没有最终结果
如果启用了连接重试，整段逻辑可能被重放，导致消息重复发送

问题的根因不是 EF Core 不行，而是数据库事务的能力边界经常被高估了。

数据库事务能保证的是“同一个数据库连接里的状态一致”，它保证不了消息队列、HTTP 调用、Redis 写入这些外部副作用跟你一起原子提交。

原理解析：EF Core 里的事务到底管到哪一步

`SaveChanges` 默认就带事务，但范围很有限

对关系型数据库来说，EF Core 在一次 SaveChanges 中默认会开启事务，确保这一批 insert/update/delete 要么全部成功，要么全部失败。

也就是说，下面这种写法本身就已经带事务语义：

order.Status = OrderStatus.Created;
inventory.Reserve(quantity);

await db.SaveChangesAsync(ct);

这个默认事务适合的场景很明确：

同一个 DbContext
同一个数据库
同一次提交
没有外部副作用参与

只有当你要把多次 SaveChanges、多段仓储调用、或跨服务动作绑在一起，就要考虑显式事务。

显式事务解决的是“多步数据库写入”

如果业务上需要多次落库，而且这些写入必须成组成功，可以显式开启事务：

await using var tx = await db.Database.BeginTransactionAsync(ct);

order.Status = OrderStatus.Created;
await db.SaveChangesAsync(ct);

payment.Status = PaymentStatus.Pending;
await db.SaveChangesAsync(ct);

await tx.CommitAsync(ct);

这类事务能解决的问题是：多次数据库操作之间不能只成功一半。

EF Core 写入链路实战：从 ChangeTracker 到 SQL Batch 的性能诊断与优化

Tue, 16 Jun 2026 17:04:23 +0800

这篇文章讨论一个问题：一次写入请求从实体变更到数据库落盘，中间到底发生了什么，哪里最容易慢，以及应该怎么定位。

问题背景

真实场景：订单系统在白天吞吐稳定，凌晨高峰出现周期性尖峰。接口平均耗时变化不大，但 P95 从 80ms 抬到 420ms，数据库 CPU 也出现波峰。

排查后发现：

应用层每次批量处理 2000 条数据
循环中频繁触发变更检测
每条数据都单独 SaveChanges
最终生成大量碎片化 SQL 往返

这类问题看起来像“数据库有点拉，扛不住了”，实际上很多成本来自应用侧写入链路组织不当。

原理解析

`ChangeTracker` 负责记录变更

EF Core 需要知道哪些实体是新增、修改、删除，这些状态都由 ChangeTracker 管理。默认情况下，EF Core 会在多个时机触发 DetectChanges，例如：

调用 SaveChanges / SaveChangesAsync
访问部分跟踪集合
某些 Add / Attach 组合场景

如果一个 DbContext 里挂了大量实体，频繁 DetectChanges 会带来明显 CPU 开销。

`SaveChanges` 并不是“一条语句”

一次 SaveChanges 大致会经历这些步骤：

执行变更检测，确定实体状态
生成修改命令（insert/update/delete）
按提供程序规则组装批次（batch）
开启事务并执行命令
成功后调用 AcceptAllChanges

性能问题通常出在 2-4 步：命令太碎、批次太小、往返太多、事务范围不合理。

SQL Batch 决定数据库往返次数

以 SQL Server 为例，EF Core 会尽可能把多条 DML 合并到一个批次中执行，但合并能力受多种因素影响：

EF Core 原生 SQL 实战：FromSql、SqlQuery 与对象映射边界

Tue, 16 Jun 2026 17:04:23 +0800

做 EF Core 一段时间后，很多人都会遇到同一个节点：常规 LINQ 能覆盖大多数查询，但一到复杂报表、视图或者历史 SQL 复用场景，就会开始考虑原生 SQL。问题不在于“能不能写 SQL”，而在于怎么写得可维护、可观测、还能和 EF Core 的映射体系配合好。这篇文章讲解 FromSql、SqlQuery 的使用边界和对象映射的一些坑。

1. 问题背景：为什么原生 SQL 常常能跑但难以长期维护

在系统演进到中后期后，下面这些场景非常常见：

报表查询需要 GROUP BY、聚合，LINQ 写出来可读性很差。
历史系统已经有稳定 SQL，需要在新服务里复用。
部分查询要精确控制执行计划，团队希望直接落 SQL。

这时候“能跑”的版本通常很快就能写出来，但过一段时间就会暴露问题：

SQL 拼接字符串，参数化做得不一致，埋下注入和计划污染风险。
映射类型定义不清晰，字段一改名就出现运行时映射异常。
查询读模型和实体模型混用，导致跟踪行为和更新语义变得混乱。
慢 SQL 能看到语句，但定位不到具体业务查询意图。

所以这篇不是教你“怎么在 EF Core 里执行 SQL”，而是讲“如何把原生 SQL 纳入 EF Core 的工程边界”。

2. 原理解析：先分清 FromSql 和 SqlQuery 的职责

FromSql 和 SqlQuery 都能执行原生 SQL，但它们解决的是不同问题。

2.1 FromSql：面向 DbSet 的查询入口

FromSql 适合挂在 DbSet 或 Set<T>() 上执行原生 SQL，典型用途有两类：

查询实体类型（可跟踪，也可 AsNoTracking）
查询 Keyless 读模型（只读投影）

关键点：

EF Core 并发冲突处理实战：乐观锁、RowVersion 与 DbUpdateConcurrencyException

Tue, 16 Jun 2026 17:04:23 +0800

并发冲突是 EF Core 里最容易被忽视、出了事又最难排查的问题之一。这篇文章聊聊它的机制、怎么配置乐观锁、冲突异常怎么处理，以及几个工程上容易踩的坑。

问题背景

真实场景：电商平台秒杀活动，同一件商品被多个请求并发扣减库存。业务日志里一切正常，但库存对不上——扣了 100 件，实际库存只减少了 60 件。

排查后发现：

多个请求几乎同时读取了库存为 200 的记录
各自在内存里把数量减掉后写回
数据库里最后一个写入覆盖了前面所有写入的结果
EF Core 没有报任何错误，因为没有配置并发控制

这就是典型的"丢失更新"（Lost Update）。

原理解析

EF Core 的并发控制模型

EF Core 支持乐观并发，不在读取时加锁，而是在写入时检测：

提交更新时，把当前数据库中读取到的"令牌值"放进 WHERE 条件，如果这行在读取之后被别人改动过，令牌不匹配，受影响行数为 0，EF Core 就会抛出 DbUpdateConcurrencyException。

生成的 SQL 大概长这样：

UPDATE Products
SET Stock = @newStock
WHERE Id = @id AND RowVersion = @originalRowVersion

如果 RowVersion 被别人改过，WHERE 匹配不到，更新语句影响 0 行，EF Core 检测到后抛异常。

两种并发令牌配置方式

方式一：[Timestamp] / IsRowVersion()（推荐）

数据库自动维护，每次行更新时自增，不需要应用层干预：

public sealed class Product
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public int Stock { get; set; }

    [Timestamp]
    public byte[] RowVersion { get; set; } = [];
}

或者在 OnModelCreating 里配置：

EF Core 慢查询排查实战：TagWith、OpenTelemetry 与执行计划

Tue, 16 Jun 2026 17:04:23 +0800

EF Core 性能问题里，最折磨人的不是“慢”，而是“慢得没规律”，线上卡，测试又无法复现。

很多小D、小W同学都经历过这种现场：

压测数据很好看
数据库 CPU 没打满
业务代码看起来也没什么大问题

你改了几个 Include，可能短期有效，但过两周又抖回来。根因往往不是某一行 LINQ 写错，而是整条排查链路没打通。

这篇文章就做一件事：给你一套能线上落地的 EF Core 慢查询定位闭环，从应用日志一路追到数据库执行计划，不靠猜。

问题背景：为什么本地快、线上慢

真实场景：订单列表接口平时 80ms 左右，高峰时段 P95 抬到 1s。你的第一反应是“数据库是不是扛不住了”，但监控显示：

数据库 CPU 长期低于 50%
连接池没有打满
磁盘 IO 没明显异常

排查下来，又遇到两个组合问题：

列表查询没有打 SQL 标签，日志里几百条 SQL 根本分不出谁是谁
某些筛选条件线上本地索引匹配不同，SQL 文本相同但参数分布不同，执行计划差异很大

也就是说，问题不是“不会优化 SQL”，而是“看不见慢点在哪”。

原理解析：慢查询定位为什么总是卡在一半

EF Core 的查询链路大致是：

LINQ 表达式翻译成 SQL
命令发送到数据库执行
结果集回传并在应用层物化

很多排查第一步都把 SQL 抓出来看看，忽略了第 2、3 步的上下文信息，比如：

这条 SQL 是哪个接口触发的
这次慢是数据库执行慢，还是返回数据太大导致物化慢
慢的是固定 SQL，还是同模板下某些参数更慢

要拿到这些信息，最实用的组合就是：

TagWith：给 SQL 打业务标签
OpenTelemetry：采集耗时、TraceId、SQL 标签并统一上报
执行计划：确认索引命中、回表、扫描和 Key Lookup

三者合起来，才能形成可服用、可验证的排查闭环。

EF Core 拦截器实战：SaveChangesInterceptor、CommandInterceptor 与审计落地

Tue, 16 Jun 2026 17:04:23 +0800

审计不是“给表补几个 CreatedBy 字段”，也不是“在业务方法里顺手记日志”。它本质上是系统级可追溯能力，设计目标是让系统在任何写路径下都能稳定回答四个问题：谁发起、改了什么、何时发生、通过哪条链路触发。

真正的难点不在 API 用法，而在系统设计阶段是否把审计定义成基础设施能力。这里聚焦两层落地：SaveChangesInterceptor 负责实体变更审计，CommandInterceptor 负责 SQL 执行审计，两者一起组成可观测、可追溯、可审计的最小闭环。

1. 问题背景：为什么审计必须在系统设计期落地

如果你刚开始做系统设计，通常会先把功能跑通，再逐步补监控、日志和审计。这条路径很正常，但系统从单一写入口演进到多入口后，审计会出现一些典型断层：

HTTP 请求有 TraceId，但数据库变更记录无法关联到具体调用链路。
Web 接口有审计字段，批处理、后台任务、集成事件消费链路没有统一审计。
SQL 慢查询能看到语句本身，但看不到对应业务场景和调用来源。
合规追查时能找到结果，找不到完整过程和责任主体。

这些现象不是某个人“写错了”，而是系统设计阶段还没有建立统一审计模型：

还没先定义统一的审计契约（身份、时间、来源、关联链路）。
写入路径没有统一审计入口，不同调用通道口径自然会分化。
变更审计和 SQL 观测没有打通，排障时很难快速复原完整链路。
只有开发约定，没有系统级自动机制，随着迭代推进就容易出现漏记。

这篇文章要解决的核心问题不是“把审计代码写到哪一层”，而是“如何在系统层提供默认生效、可验证、可扩展的审计能力”，并且让这套能力能跟着系统规模一起演进。

2. 原理解析：先拆职责，再落地拦截器

如果你是第一次从系统设计角度做审计，最稳妥的方法是先做职责拆分，再做实现落地。这里按“三步法”来理解：先统一实体变更审计，再统一 SQL 观测入口，最后明确拦截器边界。

2.1 第一步：用 SaveChangesInterceptor 统一实体变更审计

SaveChangesInterceptor 适合处理实体状态相关规则，例如：

Added 时补 CreatedAt/CreatedBy
Modified 时补 UpdatedAt/UpdatedBy
软删除时把 Deleted 改写成 Modified + IsDeleted

这类逻辑和实体状态强相关，放在拦截器里能覆盖所有调用路径，避免每个 Service 重复写一遍。

2.2 第二步：用 CommandInterceptor 统一 SQL 观测入口

DbCommandInterceptor 适合做 SQL 级别的统一观测：

慢 SQL 记录
SQL 失败统一日志
参数快照和调用耗时

它不适合做业务决策，但非常适合做“排障入口统一化”。

EF Core 查询性能实战：Include、投影与跟踪策略边界

Tue, 16 Jun 2026 17:04:23 +0800

很多团队把 EF Core 的性能问题归因于“ORM 天生慢”，但线上真实情况通常是：

查询写法对 SQL 形态不敏感
默认跟踪被滥用
图省事一次 Include 到底

结果是接口能跑，但高峰时段 P95 持续抬高，数据库 CPU 和网络带宽一起被拖上去。

这篇文章聚焦一个目标：把 EF Core 查询从“能查到数据”升级到“可预测、可解释、可优化”。

1. 问题背景：列表页为什么越改越慢

一个典型场景：订单列表页需要展示订单、客户、明细、商品。

最直觉的写法是连续 Include：

var orders = await db.Orders
    .Include(o => o.Customer)
    .Include(o => o.Items)
        .ThenInclude(i => i.Product)
    .Where(o => o.CreatedAt >= from && o.CreatedAt < to)
    .OrderByDescending(o => o.CreatedAt)
    .Take(50)
    .ToListAsync();

这段代码看起来“很完整”，但常见后果是：

结果集行数被笛卡尔放大
应用端做了大量重复对象反序列化和跟踪
实际只显示 6 个字段，却把整个对象图都拉回来了

2. 原理解析：EF Core 查询成本主要花在哪里

2.1 翻译成本

LINQ 先被转换为表达式树，再翻译成 SQL。复杂投影、方法调用、局部函数容易导致翻译退化或直接失败。

2.2 执行与网络成本

Include 深度越深，JOIN 越复杂，网络回包越大。很多慢查询不是数据库“算得慢”，而是“传得多”。

2.3 跟踪成本

默认跟踪模式会创建实体快照，便于更新，但纯读场景这部分是额外开销。

2.4 物化成本

即使 SQL 很快，应用层物化大量实体和导航属性也会抬高 CPU 与内存分配。

3. 示例代码：从全量实体到精准投影

先给出推荐的读模型查询写法：

public sealed record OrderListItemDto(
    long Id,
    string OrderNo,
    string CustomerName,
    decimal TotalAmount,
    int ItemCount,
    DateTime CreatedAt);

var query = db.Orders
    .AsNoTracking()
    .Where(o => o.CreatedAt >= from && o.CreatedAt < to)
    .OrderByDescending(o => o.CreatedAt)
    .Select(o => new OrderListItemDto(
        o.Id,
        o.OrderNo,
        o.Customer.Name,
        o.Items.Sum(i => i.Quantity * i.UnitPrice),
        o.Items.Count,
        o.CreatedAt));

var page = await query.Take(50).ToListAsync();

对于高频、形态固定的查询，可以进一步使用编译查询：

开发实战：ASP.NET Core + EF Core 实现动态可扩展的分页方案

Tue, 16 Jun 2026 17:04:23 +0800

引言

欢迎阅读，这篇文章主要面向初级开发者。

在开始之前，先问你一个问题：你做的系统，是不是每次增加一个查询条件或者排序字段，都要去请求参数对象里加一个属性，然后再跑去改 EF Core 的查询逻辑？

如果是，那这篇文章应该对你有用。我会带你做一个统一的、扩展起来不那么麻烦的分页查询方案。整体思路是四件事：统一入参、统一出参、动态排序、动态过滤。

统一请求参数

先定义一个公共的 QueryParameters 解决这个问题：

public class QueryParameters
{
    private const int MaxPageSize = 100;
    private int _pageSize = 10;

    public int PageNumber { get; set; } = 1;

    // 限制最大值，防止前端传一个很大数值把数据库搞崩了
    public int PageSize
    {
        get => _pageSize;
        set => _pageSize = value > MaxPageSize ? MaxPageSize : value;
    }

    // 支持多字段排序，格式："name desc,price asc"
    public string? SortBy { get; set; }

    // 通用关键词搜索
    public string? Search { get; set; }

    // 动态过滤条件
    public List<FilterItem> Filters { get; set; } = [];

    // 要返回的字段，逗号分隔："id,name,price"，不传则返回全部
    public string? Fields { get; set; }
}

ASP.NET Core 的模型绑定会自动把 query string 映射到这个对象，不需要手动解析。后续如果某个接口有额外参数，继承它加字段就行，不用每次从头定义。

统一响应包装器

返回值也统一一下，把分页信息和数据放在一起，调用方就不用自己拼了：

public class PagedResponse<T>
{
    // IReadOnlyList 防止外部随意修改集合
    public IReadOnlyList<T> Data { get; init; } = [];

    public int PageNumber { get; init; }
    public int PageSize { get; init; }
    public int TotalRecords { get; init; }

    public int TotalPages => (int)Math.Ceiling(TotalRecords / (double)PageSize);
    public bool HasNextPage => PageNumber < TotalPages;
    public bool HasPreviousPage => PageNumber > 1;
}

Data 是任意类型的集合，用 IReadOnlyList 防止被意外修改。TotalPages、HasNextPage 和 HasPreviousPage 三个是计算属性，不需要单独赋值。

开发实战：在 ASP.NET Core 与 EF Core 中，实现多租户数据隔离

Tue, 16 Jun 2026 17:04:23 +0800

在一个项目中，方便为多个客户提供服务，我们需要实现多租户系统。多租户系统，就是多个客户共享一个运行的项目实例，同时确保每个客户的数据安全隔离（你看不见我，我看不见你）。

这篇文章，我们将落地在 ASP.NET Core 和 Entity Framework Core 中，基于 TenantId 的全局过滤机制，实现多租户数据隔离。

原理解析

先确定隔离模型

多租户常见有三种模型：

每个租户一套数据库
共享数据库，不同 Schema
共享数据库、共享表，用 TenantId 做逻辑隔离

对大多数中小体量业务，第三种最常见，迁移成本最低，适合快速上线。

请求进入时解析租户身份
DbContext 自动带上当前租户
查询默认加 TenantId 过滤
写入自动补 TenantId

这样做以后，业务代码只关注“查什么”，不用每次都关心“记没记得加租户条件”。

ASP.NET Core + EF Core 的最小 MVP 实现

在 ASP.NET Core 里，租户信息通常来自域名、Header、Token Claim。为了演示清晰，这里我们用 Header X-Tenant-Id。

在 EF Core 里，用全局查询过滤器筛选：

modelBuilder.Entity<Order>()
    .HasQueryFilter(o => o.TenantId == _tenantProvider.TenantId);

然后在 SaveChanges 阶段，给新增实体自动写入 TenantId，避免脏数据。

示例代码

反例：手动传 tenantId

[HttpGet("orders")]
public async Task<IReadOnlyList<Order>> GetOrders([FromQuery] Guid tenantId)
{
    return await _db.Orders
        .Where(o => o.TenantId == tenantId)
        .ToListAsync();
}

这个写法的问题是隔离规则散在每个接口里，漏一次客户数据就串了。

正例：把租户隔离下沉到底层

1) 定义租户上下文

public interface ITenantProvider
{
    Guid TenantId { get; }
}

public sealed class HttpTenantProvider : ITenantProvider
{
    private readonly IHttpContextAccessor _httpContextAccessor;

    public HttpTenantProvider(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }

    public Guid TenantId
    {
        get
        {
            var headerValue = _httpContextAccessor.HttpContext?
                .Request.Headers["X-Tenant-Id"]
                .FirstOrDefault();

            if (!Guid.TryParse(headerValue, out var tenantId))
            {
                throw new InvalidOperationException("Missing or invalid X-Tenant-Id header.");
            }

            return tenantId;
        }
    }
}

2) 实体约束：需要租户字段

public interface ITenantEntity
{
    Guid TenantId { get; set; }
}

public sealed class Order : ITenantEntity
{
    public long Id { get; set; }
    public Guid TenantId { get; set; }
    public string OrderNo { get; set; } = string.Empty;
    public decimal Amount { get; set; }
    public DateTime CreatedAt { get; set; }
}

3) DbContext 全局过滤 + 自动写入 TenantId

public sealed class AppDbContext : DbContext
{
    private readonly ITenantProvider _tenantProvider;

    public AppDbContext(
        DbContextOptions<AppDbContext> options,
        ITenantProvider tenantProvider) : base(options)
    {
        _tenantProvider = tenantProvider;
    }

    public DbSet<Order> Orders => Set<Order>();

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Order>()
            .HasQueryFilter(o => o.TenantId == _tenantProvider.TenantId);

        base.OnModelCreating(modelBuilder);
    }

    public override Task<int> SaveChangesAsync(CancellationToken cancellationToken = default)
    {
        var tenantId = _tenantProvider.TenantId;

        foreach (var entry in ChangeTracker.Entries<ITenantEntity>()
                     .Where(e => e.State == EntityState.Added))
        {
            entry.Entity.TenantId = tenantId;
        }

        return base.SaveChangesAsync(cancellationToken);
    }
}

4) Program 注册

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHttpContextAccessor();
builder.Services.AddScoped<ITenantProvider, HttpTenantProvider>();

builder.Services.AddDbContext<AppDbContext>(options =>
{
    options.UseSqlServer(builder.Configuration.GetConnectionString("Default"));
});

var app = builder.Build();
app.MapControllers();
app.Run();

总结

ASP.NET Core 负责拿到租户身份，EF Core 负责做过滤和写入约束，这两层配合起来就能把多租户落地。

Ef-Core on Coding with Denglei

EF Core 事务实战：SaveChanges、ExecutionStrategy、Outbox 与一致性边界

问题背景：为什么“写成功了”不等于业务真的成功

原理解析：EF Core 里的事务到底管到哪一步

SaveChanges 默认就带事务，但范围很有限

显式事务解决的是“多步数据库写入”

EF Core 写入链路实战：从 ChangeTracker 到 SQL Batch 的性能诊断与优化

问题背景

原理解析

ChangeTracker 负责记录变更

SaveChanges 并不是“一条语句”

SQL Batch 决定数据库往返次数

EF Core 原生 SQL 实战：FromSql、SqlQuery 与对象映射边界

1. 问题背景：为什么原生 SQL 常常能跑但难以长期维护

2. 原理解析：先分清 FromSql 和 SqlQuery 的职责

2.1 FromSql：面向 DbSet 的查询入口

EF Core 并发冲突处理实战：乐观锁、RowVersion 与 DbUpdateConcurrencyException

问题背景

原理解析

EF Core 的并发控制模型

两种并发令牌配置方式

EF Core 慢查询排查实战：TagWith、OpenTelemetry 与执行计划

问题背景：为什么本地快、线上慢

原理解析：慢查询定位为什么总是卡在一半

EF Core 拦截器实战：SaveChangesInterceptor、CommandInterceptor 与审计落地

1. 问题背景：为什么审计必须在系统设计期落地

2. 原理解析：先拆职责，再落地拦截器

2.1 第一步：用 SaveChangesInterceptor 统一实体变更审计

2.2 第二步：用 CommandInterceptor 统一 SQL 观测入口

EF Core 查询性能实战：Include、投影与跟踪策略边界

1. 问题背景：列表页为什么越改越慢

2. 原理解析：EF Core 查询成本主要花在哪里

2.1 翻译成本

2.2 执行与网络成本

2.3 跟踪成本

2.4 物化成本

3. 示例代码：从全量实体到精准投影

开发实战：ASP.NET Core + EF Core 实现动态可扩展的分页方案

引言

统一请求参数

统一响应包装器

开发实战：在 ASP.NET Core 与 EF Core 中，实现多租户数据隔离

原理解析

先确定隔离模型

ASP.NET Core + EF Core 的最小 MVP 实现

示例代码

反例：手动传 tenantId

正例：把租户隔离下沉到底层

1) 定义租户上下文

2) 实体约束：需要租户字段

3) DbContext 全局过滤 + 自动写入 TenantId

4) Program 注册

总结

`SaveChanges` 默认就带事务，但范围很有限

`ChangeTracker` 负责记录变更

`SaveChanges` 并不是“一条语句”