C产品如何满足特定用户需求？

本文共计1013个文字，预计阅读时间需要5分钟。

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();（1778089113 仅限 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 拦住所有问题。