EF Core 的 SaveChangesAsync
在高并发下为什么会卡住或抛出异常
根本原因不是 EF Core 本身“不支持并发”，而是多个线程/请求共用同一个
DbContext实例，或在未处理数据库层面并发冲突的情况下直接提交修改。EF Core 默认的
DbContext是**短生命周期、非线程安全**的——它不能被多个线程同时调用
SaveChangesAsync，否则会触发
InvalidOperationException: A second operation started on this context before a previous operation completed。
常见误用场景包括：把
DbContext注册为
Singleton、在异步任务中复用同一实例、或在 Web API 中手动 new 出一个长期存活的上下文。 Web 应用必须将
DbContext注册为
Scoped（ASP.NET Core 默认行为），确保每个 HTTP 请求独占一个实例 后台任务（如
IHostedService）需自行创建作用域：
using var scope = _serviceProvider.CreateScope(); var context = scope.ServiceProvider.GetRequiredService<AppDbContext>();绝对不要跨
await边界持有并复用同一个
DbContext实例
乐观并发控制：用 [ConcurrencyCheck]
和 RowVersion
避免脏写
当多个请求几乎同时读取同一条记录、各自修改后提交，后提交者会覆盖前者的变更（丢失更新）。EF Core 提供两种主流乐观并发方案，推荐优先使用
byte[]类型的
RowVersion字段（SQL Server 的
rowversion/ PostgreSQL 的
xmin/ SQLite 的
sqlite_version语义等效列）。
1771666177或
[ConcurrencyCheck]属性标记后，EF Core 会在
UPDATE语句的
WHERE子句中加入该字段原始值。若数据库中该值已变（说明被他人改过），则
SaveChangesAsync返回 0 行受影响，并抛出
DbUpdateConcurrencyException。 实体定义示例：
public class Product
{
public int Id { get; set; }
public string Name { get; set; }
public decimal Price { get; set; }
1771666177 // 自动映射为 byte[]
public byte[] RowVersion { get; set; }
}
捕获并发异常后应重试（而非静默失败）：try
{
await context.SaveChangesAsync();
}
catch (DbUpdateConcurrencyException ex)
{
foreach (var entry in ex.Entries)
{
entry.OriginalValues.SetValues(entry.GetDatabaseValues());
}
// 可选择重试一次，或返回 409 Conflict 给客户端
}
避免对非主键字段（如 UpdatedAt）做
[ConcurrencyCheck]—— 它无法保证原子性，且易因时钟不同步导致误判
批量操作别硬扛：绕过 EF Core 走原生 SQL 或专用库
高频小更新（如计数器 +1、状态流转）用 EF Core 逐条
SaveChangesAsync会产生严重性能瓶颈：每条语句都经历变更跟踪、生成 SQL、参数绑定、网络往返。即使开启
AsNoTracking()，也无法规避 ORM 层开销。
真正有效的做法是「该用原生就用原生」：
单字段原子更新（如点赞数+1）：await context.Database.ExecuteSqlInterpolatedAsync(
$"UPDATE Posts SET LikesCount = LikesCount + 1 WHERE Id = {postId}");
批量插入/更新：用 Microsoft.Data.Sqlite（SQLite）、
Npgsql（PostgreSQL）或
SqlBulkCopy（SQL Server）直连；或引入
EFCore.BulkExtensions这类成熟扩展库 避免在循环里反复调用
SaveChangesAsync—— 即使是 Scoped 上下文，也应聚合变更后一次性提交，除非业务强要求每步独立事务
连接池与事务边界：别让 BeginTransaction
成为并发瓶颈
EF Core 默认每个
SaveChangesAsync都自动包裹在隐式事务中。高并发下大量短事务会加剧数据库连接争用和日志写入压力。显式控制事务时更需谨慎： 只在真正需要 ACID 保证的场景才用
context.Database.BeginTransaction()；多数读写分离操作无需手动事务 避免长事务：事务持续时间越长，锁持有越久，死锁风险越高。尤其不要在事务内执行 HTTP 调用、文件 IO 或长时间计算 确认数据库连接字符串已启用连接池（SQL Server 默认开启；PostgreSQL 需检查
Pooling=true）；连接池大小不足会导致
Timeout expired，可通过
Max Pool Size调整，但优先排查是否连接泄漏（如忘记
await或未释放
DbContext）
并发问题从来不在“要不要用 EF Core”，而在于是否清楚每个 API 调用背后发生了什么——比如
SaveChangesAsync不只是发 SQL，它还同步变更跟踪器、校验约束、触发事件。跳过这些环节的时机和方式，才是优化的关键分水岭。
