DbUpdateConcurrencyException 是 EF Core 的乐观并发异常，非数据库锁失败，而是因并发令牌（如[Timestamp]）检测到实体被其他操作修改后 SaveChanges() 时触发；需手动配置令牌、模拟冲突验证，并通过原始值/数据库值/当前值三者比对实现安全重试。
DbUpdateConcurrencyException 是什么，为什么它不等于“数据库冲突”
这个异常不是数据库层面的锁失败或死锁报错，而是 EF Core 在执行 SaveChanges() 时，发现当前要更新的行在加载之后已被其他操作修改过——它依赖的是你配置的并发令牌（concurrency token），比如 [Timestamp] 或 [ConcurrencyCheck] 标记的属性。没配令牌？那它根本不会抛这个异常。
如何触发并验证并发检测是否生效
最直接的方式是手动模拟：查出实体 → 另一个上下文改数据库同一行 → 当前上下文调用 SaveChanges()。注意两点：
- 必须启用并发令牌，例如在实体中加
[Timestamp]字段（类型为byte[]）或用 Fluent API 配置IsConcurrencyToken() - EF Core 默认只对被标记为
Modified的属性做 WHERE 条件，所以如果你没改任何字段但只调Update()，它仍会带旧的并发值去比对
modelBuilder.Entity<Order>()
.Property(e => e.RowVersion)
.IsRowVersion()
.IsConcurrencyToken();
捕获后怎么重试才不丢数据
不能简单地 context.Entry(entity).Reload() 再改一遍就 Save，因为用户可能已基于旧状态做了多步逻辑判断（比如库存校验、金额计算）。推荐用“客户端合并”策略：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 从异常中提取原始值（
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 只是把你回避不了的决策点，提前抛到了代码里。
