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<Product>()
.Property(p => p.RowVersion)
.IsRowVersion(); // 关键：告诉 EF 这是并发令牌
}
生成迁移后，你会看到类似：
table.Column<byte>("RowVersion", type: "rowversion", nullable: false)</byte> —— 注意不是 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—— 没这句，就是没配对。
