c# DbUpdateConcurrencyException 的处理策略

来源：这里教程网时间：2026-02-21 17:37:31 作者：

DbUpdateConcurrencyException 是什么，为什么它不等于“数据库冲突”

这个异常不是数据库层面的锁失败或死锁报错，而是 EF Core 在执行

SaveChanges()

时，发现当前要更新的行在加载之后已被其他操作修改过——它依赖的是你配置的并发令牌（

concurrency token

），比如

1771666109

或

[ConcurrencyCheck]

标记的属性。没配令牌？那它根本不会抛这个异常。

如何触发并验证并发检测是否生效

最直接的方式是手动模拟：查出实体 → 另一个上下文改数据库同一行 → 当前上下文调用

SaveChanges()

。注意两点：

必须启用并发令牌，例如在实体中加
1771666109
字段（类型为
byte[]
）或用 Fluent API 配置
IsConcurrencyToken()
EF Core 默认只对被标记为
Modified
的属性做 WHERE 条件，所以如果你没改任何字段但只调
Update()
，它仍会带旧的并发值去比对

modelBuilder.Entity<Order>()
    .Property(e => e.RowVersion)
    .IsRowVersion()
    .IsConcurrencyToken();

捕获后怎么重试才不丢数据

不能简单地

context.Entry(entity).Reload()

再改一遍就 Save，因为用户可能已基于旧状态做了多步逻辑判断（比如库存校验、金额计算）。推荐用“客户端合并”策略：

从异常中提取原始值（
ex.Entries[0].OriginalValues
）、数据库当前值（
entry.GetDatabaseValues()
）和当前修改值（
entry.CurrentValues
） 对比差异，决定是覆盖（强制提交）、放弃（回滚业务逻辑）、还是提示用户冲突（如弹窗显示两版字段差异） 若自动合并，记得手动设置
entry.OriginalValues
为数据库最新值，否则下次 Save 还会撞上同一个异常

catch (DbUpdateConcurrencyException ex)
{
    foreach (var entry in ex.Entries)
    {
        var databaseValues = entry.GetDatabaseValues();
        if (databaseValues == null)
        {
            throw new InvalidOperationException("数据库中已无此记录");
        }
        var clientValues = entry.CurrentValues.Clone();
        entry.OriginalValues.SetValues(databaseValues); // 关键：更新 Original 值
        entry.CurrentValues.SetValues(clientValues);     // 恢复用户修改
    }
    context.SaveChanges(); // 重试
}

高并发场景下，乐观锁不是万能的

它适合读多写少、冲突概率低的业务（如用户资料编辑）。但如果像秒杀扣库存这种高频写场景，靠重试 + Reload 容易形成“重试风暴”，响应延迟飙升。这时该考虑：

把关键操作下沉到存储过程 + 数据库行锁（如
UPDATE ... WHERE stock >= @need
） 用 Redis 做预占（decrement + expire），再异步落库，把并发压力从 SQL Server 转移到缓存层 避免在长事务里 hold 实体对象，尽早调用
AsNoTracking()
查询只读数据

真正难处理的从来不是异常本身，而是业务语义上“谁的修改该被保留”。