Dapper 本身不内置读写分离或多数据源管理能力，它只是一个轻量级的 ORM 工具，负责将 SQL 查询结果映射到 .NET 对象。读写分离和多数据源配置需要在 Dapper 上层通过代码逻辑或结合依赖注入、策略路由等方式实现。核心在于：**控制连接字符串的分发逻辑，让写操作走主库（Master），读操作按需走从库（Slave）**。
基于仓储层手动区分读写连接
最直接的方式是在仓储（Repository）方法中显式指定使用哪个数据库连接。适合中小项目，结构清晰、易于调试。
定义两个连接字符串：一个指向主库（支持读写），一个或多个指向从库（只读） 在仓储类中注入 IDbConnection 工厂或连接字符串，读操作用从库连接，增删改用主库连接 示例伪代码：var masterConn = new SqlConnection(_masterConnStr);
var slaveConn = new SqlConnection(_slaveConnStr);
// 写
await masterConn.ExecuteAsync("INSERT ...");
// 读
var list = await slaveConn.QueryAsync
通过接口抽象 + 依赖注入动态切换
定义 IReadConnection 和 IWriteConnection 接口，配合 DI 容器绑定不同连接实例，实现解耦。
注册时区分作用域：如AddScoped<iwriteconnection masterconnection>()</iwriteconnection>和
AddScoped<ireadconnection slaveconnection>()</ireadconnection>仓储构造函数分别接收两个接口，方法内调用对应连接 可进一步封装为 DbSession 类，内部持有一个读连接池 + 一个写连接，统一管理生命周期
借助策略模式实现负载均衡与故障转移
当有多个从库时，需考虑轮询、权重、健康检查等。Dapper 不提供这些，但可以自己扩展：
维护一个从库连接字符串列表，用简单轮询（Round-Robin）或随机选取 添加轻量心跳检测：首次使用前尝试 Open()，失败则剔除并记录日志 配合配置中心（如 AppSettings.json 或 Consul）动态刷新从库列表 避免在单次请求中混用多个从库连接——应在一个请求上下文内固定使用同一个从库，防止读取到不一致的数据（因主从延迟）注意事项与常见陷阱
读写分离不是加个从库就万事大吉，几个关键点必须注意：
事务内禁止读从库：一旦开启事务（如BeginTransaction），所有操作必须走同一连接（即主库），否则会报错或丢失一致性 强一致性场景强制走主库：例如“注册后立即查询用户”，应跳过读策略，直连主库查，避免查不到刚插入的数据 连接字符串管理别硬编码：推荐用
IConfiguration读取，支持环境区分（开发/测试/生产） 别忽略连接泄漏：Dapper 不自动管理连接生命周期，务必确保
using或
await using正确释放
基本上就这些。Dapper 的灵活性恰恰在于它不做约定，把决策权交还给开发者——读写分离不是框架功能，而是架构选择；多数据源也不是配置项，而是连接分发策略。只要理清“谁在什么时候用哪个连接”，剩下的就是组合与封装。
