应根据 DbContext 复用需求、内存开销与线程安全容忍度选择：AddDbContextPool 适合高并发读多写少场景，预创建实例并重置状态；AddDbContext（Scoped）更干净隔离，适合调试、测试及状态复杂服务。

DbContext 实例生命周期差异直接决定选哪个

用 AddDbContextPool 还是 AddDbContext，核心看的是你对 DbContext 实例复用、内存开销和线程安全的容忍边界。前者不是“性能更好就无脑换”，而是把 DbContext 实例放进池子里反复用；后者每次请求都新建一个实例（Scoped 生命周期），更“干净”但创建销毁成本略高。

AddDbContextPool 适合高并发、读多写少、DbContext 构造轻量的场景

启用连接池后，EF Core 会预创建一批 DbContext 实例（默认最小 0，最大 128），并在线程归还时重置内部状态（如变更跟踪器、缓存等），而非真正释放。但这要求你的 DbContext 构造函数不能做重操作（比如加载大配置、初始化复杂服务）、不能持有非线程安全的静态状态、且所有依赖注入的服务本身也得是 Scoped 或 Singleton。

• AddDbContextPool(options => options.UseSqlServer(...), poolSize: 64) —— 显式控制池大小，避免默认 128 在低流量服务中浪费内存
• 如果 DbContext 中手动 new 了 HttpClient 或用了 static readonly 缓存未加锁的字典，AddDbContextPool 下极易出现数据污染或并发异常
• 调用 context.Entry(x).Reload() 或显式 context.ChangeTracker.Clear() 不是必须的——池机制已自动处理，额外调用反而可能干扰内部状态

AddDbContext 更适合调试、集成测试、或 DbContext 内部状态复杂的服务

它始终保证每个请求拿到的是全新、隔离的 DbContext 实例，构造函数可自由初始化、赋值、甚至打开临时数据库连接，不会影响其他请求。单元测试里也更容易 mock 和断言。

• AddDbContext(options => options.UseSqlServer(...)) —— 默认注册为 Scoped，配合 ASP.NET Core 请求生命周期天然契合
• 若 DbContext 依赖了 IHttpContextAccessor 或需要访问当前用户 Claims，用池化时需确保这些依赖本身支持跨请求复用（通常不推荐）
• 在 Azure Functions 或短生命周期 Worker Service 中，AddDbContext 往往比池化更稳——因为连接池的预热和回收逻辑在非 Web 场景下行为不易预测

混合使用要注意 IServiceCollection 注册顺序和命名冲突

不能在同一 IServiceCollection 中既调用 AddDbContextPool 又调用 AddDbContext，否则后者会覆盖前者（或反过来），运行时只会生效最后一个。EF Core 不报错，但你的池配置实际失效。

• 检查是否误在 ConfigureServices 中写了两次注册——尤其当项目拆分多个 IServiceCollection 扩展方法时
• 若需对同一 DbContext 类型提供不同配置（比如一个用于读、一个用于写），必须用泛型参数区分，例如 AddDbContext + AddDbContextPool，而不是重复注册 AppDbContext
• 通过 services.BuildServiceProvider().GetRequiredService() 测试时，拿到的实例类型无法直接判断是否来自池——要看 AppDbContext 的 Dispose() 是否被真正调用（池化下通常不触发 Finalizer）

public void ConfigureServices(IServiceCollection services)
{
    // ✅ 正确：只注册一种方式
    services.AddDbContextPool(options =>
        options.UseSqlServer(Configuration.GetConnectionString("Default")));

    // ❌ 错误：下面这行会让上面的池注册失效
    // services.AddDbContext(options => ...);
}