EF Core 默认采用乐观并发控制，通过时间戳（RowVersion）或普通字段作为并发令牌，在 UPDATE 的 WHERE 条件中校验，冲突时抛出 DbUpdateConcurrencyException，需捕获后读取数据库值、对比并重试。
EF Core 默认采用乐观并发控制（Optimistic Concurrency Control），不锁数据，而是在 SaveChanges 或 SaveChangesAsync 执行更新/删除时，检查关键字段是否被其他操作改过。一旦发现不一致，就抛出 DbUpdateConcurrencyException，由你决定怎么处理——不是自动覆盖，而是交还控制权。
用时间戳（RowVersion）做最稳妥的并发令牌
这是推荐做法，尤其在 SQL Server 中。数据库自动生成并维护 rowversion 字段，每次更新整行都会变，完全无需业务代码干预。
- 实体类中加
[Timestamp]特性，类型为byte[]：
public class Product
{
public int Id { get; set; }
public string Name { get; set; }
[Timestamp]
public byte[] RowVersion { get; set; }
}
- EF Core 会自动把该字段加入 UPDATE 的 WHERE 条件，例如：
UPDATE Products SET Name = @p0 WHERE Id = @p1 AND RowVersion = @p2 - 若 WHERE 不匹配（说明别人已更新），影响行数为 0，触发异常
用普通字段做并发令牌（需手动维护）
适合 MySQL、PostgreSQL 等不支持 rowversion 的数据库，或业务上有意义的字段（如 LastModified、Version）。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 用 Fluent API 标记字段为并发令牌：
modelBuilder.Entity
.Property(p => p.Version)
.IsConcurrencyToken();
- 注意：你得在每次更新前主动递增或刷新这个值（比如
entity.Version++或entity.LastModified = DateTime.UtcNow） - 否则它不会变，起不到检测作用
捕获并处理 DbUpdateConcurrencyException
异常发生后，别直接报错，要读取当前数据库真实值，再决定合并策略。
- 遍历
ex.Entries获取每个冲突实体 - 调用
entry.GetDatabaseValuesAsync()拿到最新数据库快照 - 对比
OriginalValues（你加载时的值）、CurrentValues（你修改后的值）、DatabaseValues（别人刚写入的值） - 常见策略有：客户端优先（强制覆盖）、服务端优先（丢弃本次修改）、手动合并（比如只保留用户改的 Name，保留数据库的 Status）
- 调用
entry.OriginalValues.SetValues(databaseValues)同步原始值后，可重试SaveChangesAsync
避免并发问题的补充建议
- 对高竞争字段（如库存、余额），考虑结合数据库原生操作（
UPDATE ... SET Stock = Stock - 1 WHERE Stock >= 1）绕过 EF 的乐观锁逻辑 - 短事务 + 快速响应，减少“读-改-写”窗口期
- 前端提交前可加版本号校验（比如把
RowVersion作为隐藏字段传回），提前提示用户数据已变更 - 悲观锁（如
SELECT ... FOR UPDATE）在 EF Core 中需手动写原生 SQL 或使用事务隔离级别，不推荐作为默认方案
基本上就这些。核心就三点：选对令牌字段、理解 WHERE 条件怎么生成、异常来了别慌——读、比、定、重试。
