EF Core 6+ 原生不支持读写分离，需通过独立 DbContext 类型或 IDbContextFactory 显式路由主从库连接，避免混用导致跟踪冲突与一致性问题。
EF Core 6+ 原生不支持读写分离，得靠手动路由
开门见山地说，EF Core 并没有提供一个现成的 ReadReplica 或 WriteMaster 开关。所谓的“读写分离”，其本质是开发者自己来决定：当前这个 DbContext 实例应该连接到哪个数据库、执行哪一类操作。对于 EF Core 而言，它只负责执行 SQL 命令，并不区分这些命令背后的业务语义——无论是 SELECT 还是 UPDATE，在它看来都只是不同的 SQL 语句而已。
一个典型的错误场景是：系统抛出 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），最终导致了 EF Core 内部的状态跟踪机制陷入混乱。
- 因此，一个基本原则是：必须为读操作和写操作创建独立的
DbContext类型，或者至少通过不同的生命周期（例如Scoped与Transient）来隔离它们的连接实例。 - 切忌在运行时动态修改通过
DbContextOptionsBuilder.UseSqlServer(...)配置好的连接字符串；正确的做法是预先准备好两套不同的配置选项。 - 值得一提的是，EF Core 7+ 提供了
DbContextOptions选项。在调试阶段开启它，可以清晰地看到每一次查询实际连接的是哪个数据库，这对于排查路由问题非常有帮助。.EnableSensitiveDataLogging()
用 DbContextFactory + 多个连接字符串实现路由
目前来看，最稳妥、副作用最小的方案，是利用 IDbContextFactory 分别为主库和从库注入独立的工厂，然后在业务代码中显式地进行选择。这并非“全自动”的分离，但胜在完全可控、易于测试，且能避免各种隐蔽的副作用。
这种模式特别适用于典型的读多写少的高并发场景，比如电商的商品详情页：查询库存和商品信息属于读操作，可以导向从库；而下单扣减库存的写操作，则必须确保走主库。
- 首先，在服务注册时配置两个工厂：
AddDbContextFactory和(o => o.UseSqlServer(masterConn)) AddDbContextFactory。(o => o.UseSqlServer(sla veConn)) - 随后，在业务服务中分别注入
IDbContextFactory和IDbContextFactory。 - 进行写操作时，使用
await using var ctx = await _masterFactory.CreateDbContextAsync();来获取上下文实例。读操作则同理，换成_sla veFactory。 - 有一个关键优化点：对于专门用于读操作的
Sla veDbContext，建议配置options.UseQueryTrackingBeha vior(QueryTrackingBeha vior.NoTracking)。这样可以完全避免变更跟踪带来的开销，因为从库查询回来的实体本就不应该被修改。
自定义 DbContext 解决“一个类型、双连接”需求
如果项目历史包袱较重，已经存在大量代码依赖单一的 DbContext 类型，不希望拆分成两个子类，也有变通之法。可以通过构造函数传入不同的连接字符串，并在内部实现连接切换，但必须对调用方式施加严格的约束。
这里有个容易踩的“坑”：DbContext 本身是非线程安全的，并且 EF Core 默认启用了变更跟踪。如果在同一个上下文实例里，先用从库连接执行了查询，又用主库连接进行了修改，那么调用 Sa veChanges() 时，EF Core 会尝试提交所有被它跟踪的实体——这其中很可能包含了从库中读取出来的、本应是只读的数据，从而引发异常甚至导致数据被意外脏写。
- 解决方案是，让
DbContext的构造函数接收一个string connectionString参数，并在OnConfiguring方法中使用它。务必避免去重写Database.GetDbConnection()这类底层方法。 - 所有纯粹的读方法（例如
GetProductAsync），内部都必须使用从库连接字符串新建一个上下文实例（如using var ctx = new MyAppContext(_sla veConn)）。 - 同理，所有写方法（例如
CreateOrder）则使用主库连接字符串新建实例，并确保该实例在其生命周期内只执行写操作。 - 核心禁令：绝对不要复用同一个
DbContext实例跨越主从库进行操作。原因很简单，EF Core 内部的ChangeTracker并不知道你已经悄悄切换了背后的数据库。
从库延迟与事务一致性是硬伤，别指望强一致
技术方案落地后，还有一个更本质的架构问题需要清醒认识：无论是 MySQL、PostgreSQL 的主从复制，还是 SQL Server 的 Always On，都存在毫秒到秒级的数据同步延迟。这意味着，刚刚在主库完成写入的数据，立刻去从库查询，很大概率会查不到，或者查到的是旧值。
这对业务逻辑设计有直接影响：读写分离能有效分担读压力，但如果业务中隐含了“写入后必须立即读取”的逻辑（例如，Insert 后紧跟 SELECT SCOPE_IDENTITY() 获取自增ID，或使用 INSERT ... OUTPUT 语句），这类操作必须强制走主库，绝不能路由到从库。
- 对于实时性要求极高的读请求（例如订单支付状态查询、用户登录态验证），即使会给主库带来压力，也必须定向到主库。
- 只有那些能够接受最终一致性的场景（例如网站首页的商品推荐、后台的统计报表图表），才适合将流量切换到从库。
- 需要特别警惕事务：EF Core 的
BeginTransaction()只绑定到当前的DbConnection。一旦操作涉及跨主从库，分布式事务便立即失效，数据一致性无法得到保证。 - 所以，比起在代码层面追求极致的路由策略，监控从库的复制延迟（例如 MySQL 的
Seconds_Behind_Master指标）往往更为重要。当延迟突然增大时，系统应具备自动降级能力，将读请求暂时切回主库。
说到底，实现读写分离真正的难点，并不在于如何配置那几行连接字符串。真正的挑战在于，如何让整个开发团队都深刻理解：读写分离并非一个简单的、开箱即用的配置功能，而是一项需要重新审视每一个查询背后的业务语义、时效性要求和故障容忍度的系统工程。
