EF Core 本身不内置读写分离功能，但可以通过配置多个 DbContext 实例、配合不同连接字符串（读库 / 写库），再结合自定义逻辑或第三方库来实现。核心思路是：写操作走主库（master），读操作尽量走从库（slave），同时保证事务一致性与数据延迟可接受。
一、基础方案：手动区分 DbContext
为读和写分别定义两个 DbContext 子类，共用同一套实体模型，但使用不同的连接字符串：
WriteDbContext：注入主库连接字符串，用于 Add/Update/Delete 和显式事务 ReadDbContext：注入只读从库连接字符串，仅用于查询（如 ToListAsync、FirstOrDefault） 两者共享相同的OnModelCreating配置，避免映射不一致
在 DI 容器中注册时注意生命周期——通常用
Scoped即可；若需跨请求复用（如长事务），按需调整。
二、运行时动态切换连接字符串（单 DbContext）
不拆分类型，而是在 DbContext 构造或
OnConfiguring中根据当前操作类型选择连接字符串： 通过 Call Stack 或 AsyncLocal 标记当前是否处于写上下文（例如：进入 SaveChanges 前设标记） 或更简单地，在仓储层/服务层显式传入
isWrite = true/false，由工厂返回对应连接的 DbContext 实例 注意：EF Core 的 ChangeTracker 只跟踪写库上下文中的实体，切勿混用读库上下文去调 SaveChanges
三、集成中间件或 AOP 自动分流（推荐进阶）
借助 Microsoft.Extensions.DependencyInjection + Castle DynamicProxy 或 AspectCore 等 AOP 框架，实现方法级读写识别：
给仓储方法打上 [Read] / [Write] 特性 AOP 拦截器自动解析特性，并切换 DbContext 实例或连接字符串 适用于已有大量仓储代码、不想改调用方的场景四、注意事项与常见坑
读写分离不是“一配就灵”，实际落地需关注：
主从延迟：从库可能滞后几秒，强一致性读（如刚写完立刻查）必须走主库，可用策略如「写后读主」或「Session 强制读主」 事务边界：跨库事务无法保证 ACID，EF Core 的分布式事务（如 TransactionScope）在多数云数据库（如 RDS、Aurora）中不被支持，应避免 连接池隔离：读库和写库连接字符串不同，.NET 连接池天然隔离，无需额外处理 健康检查与降级：从库宕机时，应自动 fallback 到主库读取（可封装在 DbContextFactory 中）基本上就这些。不复杂但容易忽略细节，关键是把「什么时候该读主库」的规则理清楚，再选合适的实现粒度。
