EF Core 本身不内置读写分离功能，需通过多 DbContext 实例、动态切换连接字符串或 AOP 拦截等方式实现，核心是写走主库、读走从库，并处理主从延迟与事务一致性问题。
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 中）
基本上就这些。不复杂但容易忽略细节，关键是把「什么时候该读主库」的规则理清楚，再选合适的实现粒度。