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 —— 没这句，就是没配对。
