EF Core 6+ 不原生支持读写分离，需通过命名注册不同连接字符串的 DbContext 实例实现：写操作用主库（ApplicationIntent=ReadWrite），读操作用从库（ApplicationIntent=ReadOnly），事务中必须统一使用主库。
EF Core 6+ 原生支持读写分离：用 DbContextOptionsBuilder.UseSqlServer 配合连接字符串切换
EF Core 6 开始，SqlServerDbContextOptionsBuilder 提供了 EnableRetryOnFailure 和底层连接控制能力，但**原生不直接提供“读库/写库自动路由”功能**。真正可行的读写分离，依赖手动控制连接字符串来源 + DbContext 实例化策略。
核心思路是：不复用同一个 DbContext 类处理所有请求，而是按操作意图（读 or 写）创建不同实例，各自绑定对应连接字符串。
- 写操作（
SaveChanges、SaveChangesAsync）必须走主库连接字符串 - 读操作（
ToList、FirstOrDefault、AsNoTracking查询）可走从库连接字符串 - 避免在同一个
DbContext实例中混用读写 —— EF Core 不会帮你做语句重定向，它只认当前连接
如何动态注入不同 DbContext 实例：用命名服务注册 + IServiceProvider 解析
ASP.NET Core DI 容器支持命名注册，这是实现读写分离最干净的方式，比继承或工厂方法更易测试和维护。
在 Program.cs 中注册两个 DbContext 类型（注意：是同一类型，但配置不同）：
builder.Services.AddDbContext("WriteContext", options => options.UseSqlServer(builder.Configuration.GetConnectionString("Master"))); builder.Services.AddDbContext ("ReadContext", options => options.UseSqlServer(builder.Configuration.GetConnectionString("Slave")));
然后在 Controller 或 Service 中按需解析：
public class OrderService
{
private readonly AppDbContext _writeDb;
private readonly AppDbContext _readDb;
public OrderService(IServiceProvider services)
{
_writeDb = services.GetRequiredService("WriteContext");
_readDb = services.GetRequiredService("ReadContext");
}
}
- 不要把两个实例都标记为
Scoped并共用生命周期 —— 这会导致连接复用混乱 - 推荐对
ReadContext使用Transient生命周期，避免跨请求残留状态 -
AddDbContext的命名注册需配合Microsoft.Extensions.DependencyInjection扩展包（EF Core 7+ 已内置）
事务内必须强制走主库：绕过读上下文的唯一安全方式
一旦开启 BeginTransaction 或使用 [Transaction] 特性，所有后续查询（哪怕只是 Find）都必须在同一个连接上执行，否则抛出 InvalidOperationException: The connection does not support MultipleActiveResultSets 或事务隔离失败。
- 事务块中禁止使用
_readDb—— 即使你只读，EF Core 也会尝试在从库开启事务，而多数只读副本不支持写事务 - 读写混合逻辑（如“查用户 → 改订单 → 查日志”）应统一用写上下文，或拆成明确的两阶段：先读（用读库），再判断是否需要写（换写库执行）
- EF Core 没有
DbContext.SwitchConnection()这种 API；运行时切换连接字符串会破坏变更跟踪一致性，不可行
连接字符串差异与常见坑：SSL、ApplicationIntent、超时设置
从库连接字符串不是简单复制主库，必须显式声明只读意图，并适配网络与权限限制：
- SQL Server 从库必须启用
ApplicationIntent=ReadOnly，否则路由到只读副本失败（错误信息：Keyword not supported: 'applicationintent'或静默连主库） - 若启用 TLS/SSL，从库证书可能与主库不同，需加
TrustServerCertificate=true或正确配置 CA - 从库查询延迟高，建议调大
CommandTimeout（默认 30 秒不够），通过options.CommandTimeout(120)设置 - Azure SQL 弹性池或可用性组场景下，连接字符串中的
Server应指向 Listener 名称，而非具体实例 IP
典型从库连接字符串示例：
Server=my-ag-listener;Database=MyDB;ApplicationIntent=ReadOnly;TrustServerCertificate=true;Command Timeout=120;
读写分离不是开箱即用的功能，关键在于连接源头可控、事务边界清晰、连接字符串语义准确 —— 少一个环节，就可能读到旧数据或连错节点。
