Go 的 database/sql 需手动实现读写分离：封装结构体内嵌 *sql.DB，重写 Query/QueryRow 路由从库、Exec/Begin 等路由主库；事务内所有操作强制走主库；提供 WithMaster() 显式指定主库查询；主从连接池独立配置并后台健康检查。
怎么让 Go 的 database/sql 自动路由读写请求
Go 原生 database/sql 没有读写分离能力，必须自己拦截 Query、Exec 等调用做路由判断。不能靠换驱动或改 DSN 实现——那些只是连接参数，不改变行为逻辑。
核心做法是封装一个结构体，内嵌 *sql.DB，重写关键方法：
-
Query/QueryRow→ 路由到从库（slaveDB） -
Exec/Prepare/Begin→ 路由到主库（masterDB） - 事务内所有操作必须走主库，哪怕调了
Query也要强制走masterDB
别试图用 SQL 关键字（如 SELECT）字符串匹配来判断读写——ORM 或拼接语句可能绕过，且 WITH RECURSIVE、INSERT ... RETURNING 这类混合操作会误判。
事务里为什么不能切从库
事务期间任何 Query 调用如果发到从库，大概率查不到刚 INSERT 或 UPDATE 的数据，因为主从延迟存在。这不是 bug，是 MySQL/PostgreSQL 复制模型的天然限制。
立即学习“go语言免费学习笔记（深入）”；
实现时得在 Begin 返回的 *sql.Tx 上再包一层，确保它的 Query、Exec 全部透传给主库连接：
type rwTx struct {
*sql.Tx
masterDB *sql.DB // 只存引用，不重复 open
}
注意：不能把 *sql.Tx 当普通接口用，它内部持有了连接状态；直接转发调用即可，别尝试“跨库提交”。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
如何识别哪些查询真该走从库
不是所有 SELECT 都安全走从库。常见陷阱包括：
-
SELECT FOR UPDATE—— 必须主库，否则锁失效 - 刚执行过
INSERT就查同表最新记录（比如查自增 ID）——从库延迟导致查不到 - 使用了
LAST_INSERT_ID()、@@IDENTITY这类会话变量函数
稳妥做法是：默认读走从库，但提供显式 API 强制走主库，比如加个 WithMaster() 方法：
db.WithMaster().Query("SELECT ... FOR UPDATE")
比自动解析 SQL 更可靠，也更易 debug——日志里能清楚看到谁主动切了主库。
连接池和健康检查怎么不拖慢请求
主从库连接池要独立配置：SetMaxOpenConns 和 SetMaxIdleConns 得分别调，从库通常可设更大值；但别共用同一个 *sql.DB 实例，否则 Close() 会误关掉另一端。
健康检查不能同步阻塞请求。建议：
- 后台 goroutine 定期 ping 主从库（比如每 10 秒）
- 失败时标记对应实例为 “unhealthy”，后续路由跳过它
- 恢复后自动重新加入，不需重启服务
特别注意：MySQL 的 ping 默认不校验权限，得用 db.Query("SELECT 1") 才真正走查询路径；PostgreSQL 则推荐用 db.Query("SELECT 1") 或 pgx.Ping（如果用 pgx）。
读写分离中间件最难的不是路由逻辑，而是怎么让开发者感知不到主从差异，又能在出问题时快速定位到是哪个库挂了、延迟多少、有没有被误切。监控指标和日志上下文比代码本身更重要。
