EF Core不支持读写分离，动态切换ConnectionString会导致连接复用异常、事务断裂和主从延迟问题；应通过注册独立的WriteDbContext和ReadDbContext类型实现稳定读写分离。
EF Core 本身不支持读写分离，硬改 ConnectionString 或用拦截器动态切库是高危操作，大概率引发连接复用异常、事务断裂、主从延迟导致查不到刚写入的数据。 真正稳定可用的方案，是在 DbContext 实例化那一刻就绑定固定连接，而不是运行时“换库”。
为什么不能在 DbContext 创建后切换 ConnectionString
EF Core 的 DbContext 在首次访问 Database.GetDbConnection() 或执行任意命令时，会缓存底层 DbConnection 对象；后续修改 ConnectionString 不会自动关闭旧连接，也不会触发新连接池逻辑。典型现象包括：
- 第一次查询走从库，第二次却仍复用主库连接（日志里
PoolId没变） -
SaveChanges()报错Invalid operation on a closed connection，因为手动调了Close()却没Open() - 在异步上下文（如 ASP.NET Core Scoped 生命周期）中，
AsyncLocal标记失效，读操作误走主库
根本原因：EF Core 设计上假设一个 DbContext 实例对应一个稳定数据源，它不处理“换库”语义。
注册两个独立的 DbContext 类型（推荐）
最可控、最易调试的方式：定义 WriteDbContext 和 ReadDbContext 两个类，都继承自同一基类（如 AppDbContextBase），共享 OnModelCreating 配置，但各自绑定固定连接字符串。
- 在
Program.cs中分别注册，生命周期统一为Scoped：builder.Services.AddScoped<WriteDbContext>(sp => new WriteDbContext(builder.Configuration.GetConnectionString("MasterDb")))builder.Services.AddScoped<ReadDbContext>(sp => new ReadDbContext(builder.Configuration.GetConnectionString("SlaveDb"))) - 仓储接口必须拆开：
IUserWriteRepository依赖WriteDbContext，IUserReadRepository依赖ReadDbContext，避免开发人员误用从库做Add() - 不要共用同一个
DbSet<T>实例——两个上下文里的Users属性只是同名，底层连接完全隔离
IDbContextFactory 动态选库（适合多从库或灰度场景）
当需要根据租户 ID、地域或负载情况选择不同从库时，IDbContextFactory<TContext> 比硬编码两个类型更灵活。关键点是：工厂实现里不做 SQL 解析，而是基于调用上下文判断路由逻辑。
- 写操作（
Insert/Update/Delete）→ 返回主库上下文实例 - 读操作（以
AsNoTracking()或只读标记为特征）→ 返回从库上下文实例 - 可结合
AsyncLocal<bool>或自定义作用域标记（如CurrentOperation.IsWrite）识别当前意图 - 注意：EF Core 的
ChangeTracker只跟踪写库上下文中的实体，切勿混用读库上下文去调SaveChanges
强一致性读必须走主库，这个规则比技术实现更重要
从库存在复制延迟，刚写入的数据可能几秒内查不到。业务层必须明确识别哪些读属于「写后读主」场景，比如：
- 用户注册后立即跳转到个人页（需查刚插入的记录）
- 订单支付成功后展示订单详情
- 任何在
TransactionScope或显式事务内发起的读请求
这些地方不能依赖自动路由，得显式使用 WriteDbContext 或加标记强制走主库。否则问题不会立刻暴露，而是在高并发、网络抖动或主从同步慢时集中爆发——这才是最容易被忽略、也最难排查的点。
