EF Core 默认不检测并发冲突，必须显式配置并发令牌，否则后写入的请求会直接覆盖前一次修改——这就是“丢失更新”。核心思路是：读取时记下某个值，保存时拿它去比对数据库当前值，不一致就拒绝更新。
用 RowVersion 实现自动版本控制
这是最推荐的方式，数据库（如 SQL Server）会自动维护一个递增的二进制时间戳字段，EF Core 会在 UPDATE/DELETE 的 WHERE 条件中自动加入该字段比对。
在实体类中标记 1771666161 或在 Fluent API 中调用 .IsRowVersion() 无需手动赋值，插入/更新时 EF Core 自动处理byte[] RowVersion字段 生成的 SQL 类似：
UPDATE Products SET Name=@p0 WHERE Id=@p1 AND RowVersion=@p2若 WHERE 不匹配（说明数据已被他人改过），影响行数为 0，EF Core 抛出 DbUpdateConcurrencyException
用普通字段做并发令牌（IsConcurrencyToken）
适合业务语义明确的场景，比如用库存数量、订单状态或最后修改时间作为判断依据。
用 [ConcurrencyCheck] 特性，或 Fluent API 的 .IsConcurrencyToken() 字段值由业务逻辑维护，EF Core 不自动生成或修改 UPDATE 语句会把该字段也加入 WHERE，例如：WHERE Id=@p1 AND Stock=@p2注意：多个字段可同时设为并发令牌，WHERE 条件会全部包含
捕获并处理 DbUpdateConcurrencyException
异常不是错误，而是并发发生的信号。关键不是“吞掉”，而是决定怎么续上操作。
调用 entry.GetDatabaseValues() 获取数据库最新值 对比 entry.CurrentValues（用户刚改的）和 databaseValues（库中最新） 可选策略：覆盖用户输入（用库值重置 OriginalValues 后重试）、提示用户刷新再编辑、或自动合并字段（如只保留用户改的 Name，其他字段取最新值） 重试前务必调用 entry.OriginalValues.SetValues(databaseValues)，否则下次仍用旧值比对配合重试与短事务提升鲁棒性
单靠抛异常不够，生产环境需主动应对。
用 Polly 等库实现指数退避重试，例如最多 3 次，间隔 100ms、200ms、400ms 避免长事务：尽早调用 SaveChanges，不要把编辑页面停留期间的整个上下文都拖着提交 只读查询用 AsNoTracking()，减少变更追踪开销，降低冲突概率 高争用热点数据（如库存扣减），可考虑绕过 EF Core，用原生 SQL + UPDLOCK/HOLDLOCK（悲观锁）或存储过程基本上就这些。不用锁也能保一致，关键在“查—改—比—存”四步闭环，而 EF Core 已把“比”和“存”的逻辑封装好了，你只需配好令牌、接住异常、想清楚业务怎么续。
