并发冲突是 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 里配置：

modelBuilder.Entity<Product>()
    .Property(p => p.RowVersion)
    .IsRowVersion();

方式二：[ConcurrencyCheck]（字段级令牌）

不需要专门的版本字段，直接把某个业务字段标为并发令牌：

public sealed class Seat
{
    public int Id { get; set; }

    [ConcurrencyCheck]
    public string? OccupiedBy { get; set; }
}

适合"只要这个字段没被改就允许写"的场景，但精度不如 RowVersion——其他字段改了不会触发冲突检测。

DbUpdateConcurrencyException 的结构

冲突发生时，异常里携带了足够的信息用于决策：

catch (DbUpdateConcurrencyException ex)
{
    foreach (var entry in ex.Entries)
    {
        var proposedValues = entry.CurrentValues;   // 应用层想写入的值
        var originalValues = entry.OriginalValues;  // 应用层读取时的快照
        var databaseValues = await entry.GetDatabaseValuesAsync(); // 数据库现在的值
    }
}

三组值拿到手，才能做出合理的冲突解决策略。

示例代码

基础配置与迁移

public sealed class AppDbContext : DbContext
{
    public DbSet<Product> Products => Set<Product>();

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Product>()
            .Property(p => p.RowVersion)
            .IsRowVersion();
    }
}

生成迁移后，SQL Server 会把 RowVersion 字段类型映射为 rowversion，PostgreSQL 对应 xmin 系统列（用法略有差异）。

冲突重试：客户端值优先

最常见的处理策略——应用层值直接覆盖数据库值，适合"最后写入者获胜"的运营后台场景：

public async Task UpdateStockAsync(int productId, int newStock, CancellationToken ct)
{
    const int maxRetries = 3;

    for (var attempt = 0; attempt < maxRetries; attempt++)
    {
        try
        {
            var product = await db.Products.FindAsync([productId], ct)
                ?? throw new InvalidOperationException($"Product {productId} not found.");

            product.Stock = newStock;
            await db.SaveChangesAsync(ct);
            return;
        }
        catch (DbUpdateConcurrencyException ex)
        {
            if (attempt == maxRetries - 1) throw;

            // 刷新原始值快照，下一轮用新的 RowVersion 重试
            foreach (var entry in ex.Entries)
                await entry.ReloadAsync(ct);
        }
    }
}

冲突拒绝：数据库值优先

读取到冲突直接告知调用方，让用户重新决策，适合需要用户确认的场景：

public async Task<ConflictResult?> TryDeductStockAsync(
    int productId, int quantity, byte[] expectedRowVersion, CancellationToken ct)
{
    var product = await db.Products.FindAsync([productId], ct)
        ?? throw new InvalidOperationException($"Product {productId} not found.");

    if (!product.RowVersion.SequenceEqual(expectedRowVersion))
        return new ConflictResult(product.Stock, product.RowVersion);

    if (product.Stock < quantity)
        throw new InvalidOperationException("库存不足");

    product.Stock -= quantity;

    try
    {
        await db.SaveChangesAsync(ct);
        return null; // 成功
    }
    catch (DbUpdateConcurrencyException)
    {
        var dbValues = await db.Products.AsNoTracking()
            .FirstAsync(p => p.Id == productId, ct);
        return new ConflictResult(dbValues.Stock, dbValues.RowVersion);
    }
}

public record ConflictResult(int CurrentStock, byte[] CurrentRowVersion);

冲突合并：自定义字段级融合

拿到三组值后，按业务规则逐字段决策：

catch (DbUpdateConcurrencyException ex)
{
    foreach (var entry in ex.Entries)
    {
        var proposed = entry.CurrentValues;
        var database = await entry.GetDatabaseValuesAsync();

        if (database is null)
            throw new InvalidOperationException("记录已被删除，无法合并。");

        // 用数据库里最新的 Stock，保留应用层改动的 Name
        proposed["Stock"] = database["Stock"];

        // 把原始值快照更新为数据库当前值，下次提交时令牌匹配
        entry.OriginalValues.SetValues(database);
    }

    await db.SaveChangesAsync(ct);
}

总结

EF Core 的乐观并发基于"令牌比对"——写入时把读取时的快照值塞进 WHERE 条件，数据库决定这次更新是否有效。

认识这个机制的关键点有三个：

1. RowVersion 是最省心的配置方式，让数据库自动维护版本
2. DbUpdateConcurrencyException 里有三组值，决定了你能做什么样的冲突处理
3. 冲突策略（重试、拒绝、合并）要结合业务场景选择，没有通用最优解

并发冲突不是 EF Core 的问题，是分布式写入的本质问题。搞清楚它，才能在出事时不慌。