EF Core 的 DbContext 不支持多线程并发操作，因其底层数据库连接非线程安全；常见错误包括 List.ForEach 异步调用、Scoped 生命周期误用于后台任务、延迟执行导致上下文被重复占用；应优先使用 Transient 注册或手动创建作用域获取独立上下文，并避免在未 await 完成前重复使用同一实例。
为什么一并发就报 A second operation was started on this context
这不是你代码写错了，而是 EF Core 的 DbContext 本身就不支持多线程同时操作。它的底层数据库连接（比如 SQL Server 的 SqlConnection）是单线程安全的，不能并行执行多个查询或保存操作。哪怕只是两个 await _context.Users.ToListAsync() 在同一实例上“错开时间”发起，也可能因异步调度重叠而触发该异常。
常见诱因包括：
-
List.ForEach(async item => await ...)—— 看似异步，实则ForEach不等待Task，瞬间发起一堆未 await 的 DB 操作 - 在同一个
DbContext实例上调用ToListAsync()后，还没等它完成，又调了SaveChangesAsync() - 把
DbContext声明为static或注册为Singleton，导致跨请求/跨线程复用 - 延迟执行（
IEnumerable+Where）后，在foreach循环里又调用其他 DB 方法，而上下文已被前序操作占用
services.AddDbContext 怎么配才不踩坑
ASP.NET Core 默认注册方式是 Scoped（每个 HTTP 请求一个实例），这基本够用；但一旦你在后台任务、定时器、或手动启线程中使用，就很容易掉进共享实例的坑里。
正确做法是：除非明确需要长生命周期，否则一律用 Transient —— 每次从 DI 容器获取都是新实例：
services.AddDbContext(options =>
options.UseSqlServer(connectionString),
ServiceLifetime.Transient);
如果你必须在非请求上下文中用 DbContext（比如 IHostedService），那就别依赖注入字段，改用 IServiceProvider 按需创建：
using var scope = _serviceProvider.CreateScope(); var context = scope.ServiceProvider.GetRequiredService这样能确保每次 DB 操作都拥有独立、干净的上下文。
ToList()、FirstOrDefault()这些方法真能救命？能，但只解决“延迟执行引发的嵌套访问”这一类问题，不是万能解药。它们的作用是把查询**立即执行并加载进内存**，切断后续对数据库的隐式依赖。
例如下面这段危险代码：
var users = _context.Users.Where(u => u.IsActive); // IQueryable → 延迟执行 foreach (var user in users) // 第一次枚举 → 触发查询 { user.LastLogin = DateTime.UtcNow; await _context.SaveChangesAsync(); // ❌ 此时上下文还在忙 users 查询！ }改成：
var users = await _context.Users.Where(u => u.IsActive).ToListAsync(); // ✅ 立即取回全部到内存 foreach (var user in users) { user.LastLogin = DateTime.UtcNow; } await _context.SaveChangesAsync(); // ✅ 上下文此时空闲注意：
ToListAsync()是异步版，必须await；而ToList()是同步阻塞调用，Web 场景中严禁使用。异步循环里最容易翻车的写法
List.ForEach和foreach (var x in list)在异步语境下行为完全不同：
-
list.ForEach(async x => await：编译通过，但实际是“发射一堆没 await 的 Task”，等于并发打 DB
DoDbWork(x))
-
foreach (var x in list) { await DoDbWork(x); }：顺序执行，安全 - 想真正并发处理？用
Task.WhenAll(list.Select(x => DoDbWork(x)))，但前提是每个DoDbWork内部都新建自己的DbContext实例
一句话：只要涉及多个异步 DB 调用，就别图省事用 ForEach，老实用 foreach + await，或者拆成独立服务+独立上下文。
最常被忽略的一点：即使你没写多线程代码，EF Core 的异步 I/O 调度也可能让两个 await 在极短时间内抢占同一个上下文——所以“await 之后再用”不是建议，是强制要求。
