动态切换EF Core连接字符串需在DbContext构造函数传入Func或IConfiguration，注册为Scoped/Transient而非Singleton；SQL Server与PostgreSQL需分离DbContext类，共享配置；迁移须按Provider分目录管理；租户场景注意AsyncLocal丢失、注入防护及连接池限制。
EF Core 连接字符串怎么动态换，不重启应用
靠改 DbContext 构造函数传入的连接字符串最直接。EF Core 本身不维护“全局连接池”，连接由 DbContext 实例持有，所以只要每次创建 DbContext 时传不同字符串，就自然切换了数据库。
常见错误是把 DbContext 注册成单例（Singleton）——这会让所有请求共用同一个连接字符串，动态切换完全失效。
- 注册必须用
Scoped或Transient：比如services.AddDbContextPool本身是 Scoped 行为，没问题；但别写(...) AddSingleton - 不要在
OnConfiguring里硬编码字符串，它只执行一次，无法响应运行时变化 - 推荐做法：构造函数接收一个
Func或IConfiguration，让上层决定当前该连哪个库
示例：
public class AppDbContext : DbContext
{
private readonly Func<string> _connectionStringFactory;
public AppDbContext(Func<string> connectionStringFactory)
=> _connectionStringFactory = connectionStringFactory;
protected override void OnConfiguring(DbContextOptionsBuilder options)
=> options.UseSqlServer(_connectionStringFactory()); // 或 UseNpgsql 等
}</string></string>
SQL Server 和 PostgreSQL 怎么共存一套 DbContext
不能共用同一套 DbContext 类直接切 Provider，因为 UseSqlServer 和 UseNpgsql 是互斥的扩展方法，且底层类型（如生成的 SQL、数据类型映射）完全不同。
真正可行的是「抽象出共享逻辑，具体 DbContext 分离」：
- 定义公共实体基类和
IEntityTypeConfiguration实现，放在独立类库中 - 为 SQL Server 写
SqlServerDbContext : DbContext，为 PostgreSQL 写PostgreSqlDbContext : DbContext - 两个 DbContext 分别调用
modelBuilder.ApplyConfigurationsFromAssembly加载同一组配置 - 业务层通过接口（如
ICustomerRepository）隔离，不依赖具体 DbContext 类型
注意：DateTimeOffset、JSON 字段、索引语法等在两边行为差异大，配置里得加 #if NET7_0_OR_GREATER 或运行时判断 Provider 类型再分支处理。
切换数据库时迁移（Migrations）怎么不炸
EF Core 的 dotnet ef migrations 命令默认绑定到某个 Provider（比如你装了 Microsoft.EntityFrameworkCore.SqlServer 包，就只能为 SQL Server 生成迁移）。想支持多库，迁移文件本身就得按目标数据库分组管理。
- 每个数据库对应一个独立的迁移程序集：用
-o指定不同输出目录，比如dotnet ef migrations add Init --project SqlServerProject -o Migrations/SqlServer - 运行时执行迁移前，必须确保当前
DbContext使用的 Provider 和迁移文件生成时一致，否则context.Database.Migrate()会抛InvalidOperationException：“The migration 'xxx' was written for provider 'Npgsql.EntityFrameworkCore.PostgreSQL' but the current provider is 'Microsoft.EntityFrameworkCore.SqlServer'” - 别把多个 Provider 的迁移混在一个
Migrations文件夹里——EF Core 会尝试全部加载，报错或漏执行
租户场景下按请求头或用户 ID 切库，要注意什么
典型做法是在中间件里解析租户标识（如 X-Tenant-Id），然后把它塞进 AsyncLocal 或 IServiceScopeFactory 创建的 Scope 中，供 DbContext 构造时读取。
容易踩的坑：
-
AsyncLocal在 await 后可能丢失值，尤其用了非标准 Task 调度器（比如某些 gRPC 或 SignalR 场景），建议用HttpContext.RequestServices配合 Scoped 服务传递 - 连接字符串拼接时没校验租户 ID 合法性，导致注入风险：必须白名单过滤或查库确认租户存在后再拼接
- 没控制连接池大小，每个租户都新建连接池，最终耗尽数据库连接数——用
SqlServerOptionsExtensions.MaxPoolSize或NpgsqlConnection.GlobalTypeMapper相关配置限流
复杂点在于：租户间表结构可能有微小差异（比如 A 租户多一个字段），这时光靠动态连接串不够，还得配合 EF Core 的 ModelCustomizer 或运行时修改 IMutableEntityType ——那已经超出“切换”范畴，进入多租户 Schema 管理了。
