EF Core 的
AddDbContextPool是专为高并发场景设计的性能优化手段，它通过复用
DbContext实例减少创建/销毁开销，而不是每次请求都新建一个上下文。它不是“万能加速器”，是否启用、如何配置，得看你的应用负载特征。
什么时候该用 DbContext 池
池化真正起作用的前提是：请求密集、单次操作轻量、DbContext 生命周期短（如 Web API 的每个 HTTP 请求）。典型适用场景包括：
ASP.NET Core Web API 或 MVC 应用，QPS 较高（例如 >100） 多数操作只读或简单增删改，不涉及长时间事务或跨请求状态保持 没有手动共享 DbContext 实例（比如把 DbContext 存在静态字段或 Session 中） 已确认数据库连接池（由 ADO.NET 驱动管理）本身已调优，瓶颈不在连接建立上怎么注册 DbContext 池
只需替换常规的
AddDbContext为
AddDbContextPool，其余配置方式一致：
Program.cs（.NET 6+）
builder.Services.AddDbContextPool<ApplicationDbContext>(options =>
options.UseSqlServer(builder.Configuration.GetConnectionString("Default")));
如果需要自定义池大小（默认 1024），可传入
poolSize参数：
builder.Services.AddDbContextPool<ApplicationDbContext>(options =>
options.UseSqlServer(connectionString), poolSize: 256);
注意：
poolSize不是并发上限，而是“最多缓存多少个干净实例”。超出后 EF Core 会退回到非池化模式（即每次 new 一个），不会报错但失去池化收益。
池化对 DbContext 行为的影响
启用池化后，EF Core 会在每次归还实例时自动执行清理，确保下一次租用时是干净的：
自动重置ChangeTracker：所有被跟踪的实体状态清空 清除内部缓存（如编译查询缓存仍保留，但一级缓存不跨租用） 不重置数据库连接——连接本身由底层 ADO.NET 连接池管理，两者正交 仍需遵循“每个请求一个 DbContext”原则；池化只是让这个“一个”更廉价
哪些情况不适合用池
盲目开启池可能带来反效果或隐患：
低并发应用（如内部工具、后台定时任务）：实例创建开销本就不明显，池反而增加内存和管理成本 DbContext 被长期持有（如挂载在 Singleton 服务中）：池机制失效，且极易引发线程安全问题 自定义了复杂初始化逻辑（如 OnConfiguring 中加载大量配置或打开长连接）：池化会放大这部分开销 使用了某些未适配池化的第三方扩展（极少见，但需验证）基本上就这些。用不用池，先压测对比；怎么调大小，看监控中的租用等待率和 GC 压力——不复杂但容易忽略。
