dbcontextpool 是 ef core 提供的轻量级对象池，通过复用 dbcontext 实例避免频繁构造、di 解析和连接初始化开销，提升高并发 web api 性能；需用 adddbcontextpool 注册，注意状态重置、构造函数参数限制及适用场景。
DbContextPool 是什么，为什么能提升性能
DbContextPool 是 EF Core 提供的轻量级对象池实现，它复用 DbContext 实例而非每次请求都新建——避免了频繁构造、依赖注入解析、数据库连接初始化等开销。它特别适合高并发、短生命周期的 Web API 场景（比如 ASP.NET Core 中每个 HTTP 请求对应一个 DbContext）。但要注意：池中每个 DbContext 仍需在使用前重置内部状态（如变更跟踪器、缓存），所以它不是“共享上下文”，而是“安全复用上下文”。
AddDbContextPool 的正确注册方式
必须在 Program.cs（.NET 6+）中用 AddDbContextPool 替代 AddDbContext，且不能同时注册两者。默认池大小为 1024，可按需调整：
builder.Services.AddDbContextPool<AppDbContext>(options =>
{
options.UseSqlServer(builder.Configuration.GetConnectionString("Default"));
}, poolSize: 256);
- 池大小不宜盲目调大：过大会增加内存占用，且超出实际并发数后无收益
- 必须确保
AppDbContext构造函数只接收由 DI 容器提供的服务（如IOptions、ILogger），不能传入请求作用域内变化的值（如HttpContext） - 不支持 scoped 生命周期的 DbContext 注入点——
AddDbContextPool本身注册的是 singleton，EF Core 内部通过池管理实例生命周期
哪些场景下 AddDbContextPool 反而有害
池化不是银弹。以下情况建议退回 AddDbContext（scoped）：
- DbContext 被长期持有（如后台任务中跨多个 await、或作为单例字段缓存）——池中实例可能被其他请求中途回收重置
- 自定义了非线程安全的 DbContext 扩展（比如手动维护未同步的缓存字典）
- 启用了
EnableSensitiveDataLogging(true)且日志输出依赖上下文状态——池中实例重置不保证日志配置完全清空 - 使用了第三方库直接 new DbContext() 或绕过 DI 获取实例——池机制完全失效
验证是否真的走池路径
最直接的方式是观察日志：启用 EF Core 日志后，若看到类似 DbContext was created from pool 或 DbContext was returned to pool 的消息，说明生效。也可在 AppDbContext 构造函数里加断点或日志输出，对比 AddDbContext 和 AddDbContextPool 下的调用频次——池化后构造函数执行次数应显著低于请求总数。
容易被忽略的一点是：池只对通过 DI 获取的 DbContext 生效；如果你在 service 层里写了 new AppDbContext(...)，哪怕注册了池也毫无意义。
