17370845950

EF Core 默认采用乐观并发控制，通过时间戳（RowVersion）或普通字段作为并发令牌，在 UPDATE 的 WHERE 条件中校验，冲突时抛出 DbUpdateConcurrencyException，需捕获后读取数据库值、对比并重试。

EF Core 默认采用乐观并发控制（Optimistic Concurrency Control），不锁数据，而是在 SaveChanges 或 SaveChangesAsync 执行更新/删除时，检查关键字段是否被其他操作改过。一旦发现不一致，就抛出 DbUpdateConcurrencyException，由你决定怎么处理——不是自动覆盖，而是交还控制权。

用时间戳（RowVersion）做最稳妥的并发令牌

这是推荐做法，尤其在 SQL Server 中。数据库自动生成并维护 rowversion 字段，每次更新整行都会变，完全无需业务代码干预。

• 实体类中加 1769312319 特性，类型为 byte[]：

public class Product
{
  public int Id { get; set; }
  public string Name { get; set; }
  1769312319
  public byte[] RowVersion { get; set; }
}

• EF Core 会自动把该字段加入 UPDATE 的 WHERE 条件，例如：
  UPDATE Products SET Name = @p0 WHERE Id = @p1 AND RowVersion = @p2
• 若 WHERE 不匹配（说明别人已更新），影响行数为 0，触发异常

用普通字段做并发令牌（需手动维护）

适合 MySQL、PostgreSQL 等不支持 rowversion 的数据库，或业务上有意义的字段（如 LastModified、Version）。

• 用 Fluent API 标记字段为并发令牌：

modelBuilder.Entity()
  .Property(p => p.Version)
  .IsConcurrencyToken();

• 注意：你得在每次更新前主动递增或刷新这个值（比如 entity.Version++ 或 entity.LastModified = DateTime.UtcNow）
• 否则它不会变，起不到检测作用

捕获并处理 DbUpdateConcurrencyException

异常发生后，别直接报错，要读取当前数据库真实值，再决定合并策略。

• 遍历 ex.Entries 获取每个冲突实体
• 调用 entry.GetDatabaseValuesAsync() 拿到最新数据库快照
• 对比 OriginalValues（你加载时的值）、CurrentValues（你修改后的值）、DatabaseValues（别人刚写入的值）
• 常见策略有：客户端优先（强制覆盖）、服务端优先（丢弃本次修改）、手动合并（比如只保留用户改的 Name，保留数据库的 Status）
• 调用 entry.OriginalValues.SetValues(databaseValues) 同步原始值后，可重试 SaveChangesAsync

避免并发问题的补充建议

• 对高竞争字段（如库存、余额），考虑结合数据库原生操作（UPDATE ... SET Stock = Stock - 1 WHERE Stock >= 1）绕过 EF 的乐观锁逻辑
• 短事务 + 快速响应，减少“读-改-写”窗口期
• 前端提交前可加版本号校验（比如把 RowVersion 作为隐藏字段传回），提前提示用户数据已变更
• 悲观锁（如 SELECT ... FOR UPDATE）在 EF Core 中需手动写原生 SQL 或使用事务隔离级别，不推荐作为默认方案

基本上就这些。核心就三点：选对令牌字段、理解 WHERE 条件怎么生成、异常来了别慌——读、比、定、重试。