RowVersion 是 sql Server 的自增二进制字段，EF Core 用其在 WHERE 子句中校验旧值实现乐观并发控制；需 byte[] 属性 + IsRowVersion() 配置 + rowversion 列类型，否则失效。
EF Core 中 RowVersion 是什么，为什么能解决并发冲突
RowVersion（也叫 timestamp）是 SQL Server 提供的一种自增二进制字段，每次行更新时数据库自动更新其值。EF Core 利用它在 UPDATE 或 delete 语句的 WHERE 子句中加入该字段的旧值，一旦数据库里当前值已变（说明被别人改过），SQL 就不会匹配到行，EF Core 捕获到“0 行受影响”，就抛出 DbUpdateConcurrencyException。
它不是靠锁、也不是靠业务时间戳，而是靠数据库原生的乐观并发控制机制——轻量、无阻塞、适合高读低写场景。
怎么在实体和迁移中正确配置 RowVersion
必须同时满足三个条件，RowVersion 才生效：
- 实体类中定义一个
byte[]类型的属性（命名任意，但习惯叫RowVersion或Timestamp） - 在
OnModelCreating中用IsRowVersion()标记该属性 - 确保数据库列类型是
rowversion（EF Core 迁移会自动处理）
示例：
public class Product { public int Id { get; set; } public string Name { get; set; } public byte[] RowVersion { get; set; } // 必须是 byte[] }protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity() .Property(p => p.RowVersion) .IsRowVersion(); // 关键：告诉 EF 这是并发令牌 } 生成迁移后，你会看到类似：table.column —— 注意不是 timestamp（已弃用），也不是 datetime2。
捕获并处理 DbUpdateConcurrencyException
EF Core 不会自动重试或合并，你得自己 catch 异常，检查哪些属性冲突、决定怎么处理（刷新再提交？提示用户？丢弃本地修改？）。
关键点：
-
Entries属性包含所有参与本次失败更新的EntityEntry -
Entry.OriginalValues["RowVersion"]是你加载时的旧值 -
Entry.GetDatabaseValues()可查数据库当前最新值（需重新查询） - 调用
Entry.OriginalValues.SetValues(currentDbValues)后再SaveChanges()就是“覆盖式重试”
简单重试示例：
try { context.SaveChanges(); } catch (DbUpdateConcurrencyException ex) { foreach (var entry in ex.Entries) { var databaseValues = entry.GetDatabaseValues(); if (databaseValues == null) { throw new InvalidOperationException("数据库中该记录已被删除"); } entry.OriginalValues.SetValues(databaseValues); // 用数据库值覆盖 Original } context.SaveChanges(); // 再试一次 }常见踩坑点：为什么 RowVersion 没起作用
最常遇到的失效场景：
- 实体类属性类型不是
byte[]（比如用了long或DateTime）→ EF Core 完全忽略，不加 WHERE 条件 - 忘了调用
IsRowVersion()→ 迁移里建的是普通varbinary，数据库不自动更新，EF 也不做并发检查 - 手动给
RowVersion赋值（如new byte[8]）→ 破坏数据库自动生成逻辑，下次更新必然失败 - 使用了
AsNoTracking()查询后直接修改并Attach()→OriginalValues为空，EF 无法构造 WHERE 条件，等同于关闭并发检查 - SQL Server 兼容级别太低（如 rowversion 行为异常，建议至少 120+
调试时可开启 EF 日志，看生成的 SQL 是否含 WHERE [RowVersion] = @p1 —— 没这句，就是没配对。