应根据 DbContext 复用需求、内存开销与线程安全容忍度选择：AddDbContextPool 适合高并发读多写少场景，预创建实例并重置状态；AddDbContext（Scoped）更干净隔离，适合调试、测试及状态复杂服务。
DbContext 实例生命周期差异直接决定选哪个
用 AddDbContextPool 还是 AddDbContext，核心看的是你对 DbContext 实例复用、内存开销和线程安全的容忍边界。前者不是“性能更好就无脑换”，而是把 DbContext 实例放进池子里反复用；后者每次请求都新建一个实例（Scoped 生命周期），更“干净”但创建销毁成本略高。
AddDbContextPool 适合高并发、读多写少、DbContext 构造轻量的场景
启用连接池后，EF Core 会预创建一批 DbContext 实例（默认最小 0，最大 128），并在线程归还时重置内部状态（如变更跟踪器、缓存等），而非真正释放。但这要求你的 DbContext 构造函数不能做重操作（比如加载大配置、初始化复杂服务）、不能持有非线程安全的静态状态、且所有依赖注入的服务本身也得是 Scoped 或 Singleton。
-
AddDbContextPool<AppDbContext>(options => options.UseSqlServer(...), poolSize: 64)—— 显式控制池大小，避免默认 128 在低流量服务中浪费内存 - 如果 DbContext 中手动 new 了
HttpClient或用了static readonly缓存未加锁的字典，AddDbContextPool下极易出现数据污染或并发异常 - 调用
context.Entry(x).Reload()或显式context.ChangeTracker.Clear()不是必须的——池机制已自动处理，额外调用反而可能干扰内部状态
AddDbContext 更适合调试、集成测试、或 DbContext 内部状态复杂的服务
它始终保证每个请求拿到的是全新、隔离的 DbContext 实例，构造函数可自由初始化、赋值、甚至打开临时数据库连接，不会影响其他请求。单元测试里也更容易 mock 和断言。
-
AddDbContext<AppDbContext>(options => options.UseSqlServer(...))—— 默认注册为 Scoped，配合 ASP.NET Core 请求生命周期天然契合 - 若 DbContext 依赖了
IHttpContextAccessor或需要访问当前用户 Claims，用池化时需确保这些依赖本身支持跨请求复用（通常不推荐） - 在 Azure Functions 或短生命周期 Worker Service 中，
AddDbContext往往比池化更稳——因为连接池的预热和回收逻辑在非 Web 场景下行为不易预测
混合使用要注意 IServiceCollection 注册顺序和命名冲突
不能在同一 IServiceCollection 中既调用 AddDbContextPool<T> 又调用 AddDbContext<T>，否则后者会覆盖前者（或反过来），运行时只会生效最后一个。EF Core 不报错，但你的池配置实际失效。
- 检查是否误在
ConfigureServices中写了两次注册——尤其当项目拆分多个IServiceCollection扩展方法时 - 若需对同一 DbContext 类型提供不同配置（比如一个用于读、一个用于写），必须用泛型参数区分，例如
AddDbContext<ReadDbContext>+AddDbContextPool<WriteDbContext>，而不是重复注册AppDbContext - 通过
services.BuildServiceProvider().GetRequiredService<AppDbContext>()测试时，拿到的实例类型无法直接判断是否来自池——要看AppDbContext的Dispose()是否被真正调用（池化下通常不触发 Finalizer）
public void ConfigureServices(IServiceCollection services)
{
// ✅ 正确：只注册一种方式
services.AddDbContextPool<AppDbContext>(options =>
options.UseSqlServer(Configuration.GetConnectionString("Default")));
// ❌ 错误：下面这行会让上面的池注册失效
// services.AddDbContext<AppDbContext>(options => ...);
}
DbContext 池不是银弹，它的“省”建立在“你没在构造函数里埋雷”和“你没在 OnConfiguring/OnModelCreating 里偷偷改单例状态”的前提上。一旦出问题，表现往往是偶发性数据错乱或 ObjectDisposedException，排查起来比普通 DbContext 问题更隐蔽。 
