17370845950

DbUpdateConcurrencyException 是 EF Core 的乐观并发异常，非数据库锁失败，而是因并发令牌（如1768812935）检测到实体被其他操作修改后 SaveChanges() 时触发；需手动配置令牌、模拟冲突验证，并通过原始值/数据库值/当前值三者比对实现安全重试。

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

这个异常不是数据库层面的锁失败或死锁报错，而是 EF Core 在执行 SaveChanges() 时，发现当前要更新的行在加载之后已被其他操作修改过——它依赖的是你配置的并发令牌（concurrency token），比如 1768812935 或 [ConcurrencyCheck] 标记的属性。没配令牌？那它根本不会抛这个异常。

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

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

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

modelBuilder.Entity()
    .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() 查询只读数据

真正难处理的从来不是异常本身，而是业务语义上“谁的修改该被保留”。DbUpdateConcurrencyException 只是把你回避不了的决策点，提前抛到了代码里。