EF Core 6+ 原生不支持读写分离，需通过独立 DbContext 类型或 IDbContextFactory 显式路由主从库连接，避免混用导致跟踪冲突与一致性问题。
EF Core 6+ 原生不支持读写分离，得靠手动路由
EF Core 没有内置的 ReadReplica 或 WriteMaster 配置开关。所谓“读写分离”，本质是你自己决定：这个 DbContext 实例连哪个连接字符串、执行哪类操作。EF Core 只管执行 SQL，不区分语义——SELECT 和 UPDATE 对它来说只是不同命令。
常见错误现象：InvalidOperationException: The instance of entity type 'User' cannot be tracked because another instance with the same key value is already being tracked. —— 这往往是因为你用同一个 DbContext 实例混用了主库和从库连接（比如手动切换 Database.GetDbConnection().ConnectionString），导致内部状态混乱。
- 必须为读、写场景创建**独立的
DbContext类型**，或至少用不同生命周期（如ScopedvsTransient）隔离连接实例 - 不要在运行时动态修改
DbContextOptionsBuilder.UseSqlServer(...)的连接字符串；应预先配置好两套选项 - EF Core 7+ 支持
DbContextOptions<t>.EnableSensitiveDataLogging()</t>，调试时打开它能看清每次查询实际连的是哪个数据库
用 DbContextFactory + 多个连接字符串实现路由
最稳妥的做法是用 IDbContextFactory<t></t> 分别注入主库和从库的工厂，由业务代码显式选择。这不是“自动”分离，但可控、可测、无副作用。
使用场景：高并发读多写少的服务（如商品详情页查库存 + 下单），需要把报表类 SELECT 导向从库，而 SaveChanges() 必须走主库。
- 注册两个工厂：
AddDbContextFactory<masterdbcontext>(o => o.UseSqlServer(masterConn))</masterdbcontext>和AddDbContextFactory<slavedbcontext>(o => o.UseSqlServer(slaveConn))</slavedbcontext> - 在 Service 中分别注入
IDbContextFactory<masterdbcontext></masterdbcontext>和IDbContextFactory<slavedbcontext></slavedbcontext> - 写操作用
await using var ctx = await _masterFactory.CreateDbContextAsync();，读操作同理换_slaveFactory - 注意：
SlaveDbContext应设options.UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking)，避免无谓开销
自定义 DbContext 解决“一个类型、双连接”需求
如果不想拆成两个 DbContext 子类（比如已有大量代码依赖单一类型），可以用构造函数参数 + 内部连接切换，但必须严格约束调用方式。
容易踩的坑：DbContext 是非线程安全的，且 EF Core 默认开启变更跟踪。若在同一个实例里先查从库、再改主库，SaveChanges() 会尝试提交所有已跟踪实体——其中可能包含从库读出来的只读数据，引发异常或脏写。
- 构造函数接收
string connectionString，并在OnConfiguring中传入；禁止重写Database.GetDbConnection() - 所有读方法（如
GetProductAsync）必须新建DbContext实例（using var ctx = new MyAppContext(_slaveConn)） - 所有写方法（如
CreateOrder）同理用_masterConn，且确保该实例生命周期内**只做写** - 不能复用
DbContext实例跨库操作；EF Core 的ChangeTracker不知道你换库了
从库延迟与事务一致性是硬伤，别指望强一致
MySQL/PostgreSQL 的主从复制有毫秒到秒级延迟，SQL Server Always On 可能更低，但依然存在窗口期。这意味着：刚写完立刻去从库查，大概率查不到或查到旧值。
性能影响：从库分担读压力有效，但若业务逻辑隐含“写后必读”，比如 Insert + SELECT SCOPE_IDENTITY() 或 INSERT ... OUTPUT，这类操作绝不能走从库。
- 对实时性敏感的读（如订单支付结果、用户登录态）必须走主库，哪怕暂时扛压
- 允许最终一致的场景（如首页推荐、统计图表）才适合切到从库
- 不要在事务中混用主从连接；EF Core 的
BeginTransaction()只绑定当前DbConnection，跨库即失效 - 监控从库延迟（如 MySQL 的
Seconds_Behind_Master）比优化代码更重要——延迟突增时，自动降级回主库读
真正难的不是怎么配连接字符串，是怎么让团队所有人理解：读写分离不是加个配置就能开箱即用的功能，而是要重新梳理每个查询背后的语义、时效要求和失败容忍度。
