ef core并发冲突必须显式处理，否则必然丢数据；需配置isrowversion()或[timestamp]启用乐观锁，校验rowversion字段防止丢失更新，未配置时update语句仅含主键where条件，导致后提交者静默覆盖前提交者修改。
EF Core 的并发更新冲突必须显式处理，否则后提交者会静默覆盖前提交者的修改——这不是“可能丢数据”，而是“必然丢数据”。
为什么 SaveChangesAsync 会直接覆盖别人改的值
默认情况下，EF Core 生成的 UPDATE 语句只带主键 WHERE 条件：UPDATE Products SET Stock = @newStock WHERE Id = @id。它不校验该记录自你读取以来是否被他人动过。只要主键匹配，就无条件写入。
- 典型现象：前端连续点两次“减库存”，数据库只减了 1 次；两个用户同时编辑同一条订单，后保存的人把前一个人改的地址、备注全冲掉了
- 根本原因不是并发量大，而是实体类没声明任何并发令牌（Concurrency Token）
-
[ConcurrencyCheck]只校验被标记字段本身是否被别人改过；但如果你只标了Name，而别人改了Price和Stock，这次更新依然能成功——它不防“部分字段被覆盖”
用 IsRowVersion() 配置数据库原生行版本列（推荐）
SQL Server 的 rowversion、PostgreSQL 的 xmin、SQLite 的内部版本号，是数据库自动维护的递增标识，比时间戳或 GUID 更可靠、更轻量。
- 实体中必须定义为
byte[]类型且不可为 null：public byte[] RowVersion { get; set; } = []; - 必须用 Fluent API 显式启用：
modelBuilder.Entity<product>().Property(p => p.RowVersion).IsRowVersion();</product>（[Timestamp]仅限 SQL Server，跨库迁移时会失效） - 数据库对应列类型必须匹配：SQL Server 中建表时得是
rowversion，不能是binary(8)或varbinary—— 否则 EF Core 不会把它当版本列用 - 别手动给
RowVersion赋值，EF Core 会在每次 SaveChanges 时忽略你设的值，由数据库自动生成
捕获 DbUpdateConcurrencyException 后怎么安全重试
抛出这个异常说明数据库已拒绝更新，此时不能再简单地 SaveChangesAsync() 重来——因为实体里还存着旧的原始值快照，而数据库已是新状态。
- 最简做法是 reload：
entry.Reload(); await context.SaveChangesAsync();，但这会丢掉用户本次想改的字段（比如只改了Stock，reload 后Name也被刷成数据库当前值） - 稳妥做法是合并：从
entry.CurrentValues提取用户真正要改的字段（如Stock），再从entry.GetDatabaseValues()拿当前真实值，把Stock值设回CurrentValues，最后再 Save - 绝对不要在 catch 里写
context.Entry(x).State = EntityState.Modified——这会清除原始值快照，下次冲突时连“谁改了哪部分”都判断不了 - 高频场景（如秒杀）不能只靠重试：1000 个请求读到库存=1，999 个注定失败。业务层必须前置校验：
SELECT Stock FROM Products WHERE Id = @id→ 判断是否足够 → 再走更新逻辑
别把乐观锁当成万能解药
它解决的是“丢失更新”，但掩盖不了设计缺陷。比如一个订单实体同时包含基础信息（CustomerName）、物流信息（TrackingNumber）、支付信息（PaidAt），全塞进一张表+一个 RowVersion，会导致任意模块修改都引发全局冲突。
更合理的做法是按业务边界拆分聚合根，或对不同字段组使用不同并发策略——比如物流字段用 [ConcurrencyCheck]，支付字段走状态机校验，而不是指望一个 RowVersion 拦住所有问题。
