Go语言读写分离必须用独立*sql.DB实例，主库处理写和强一致性读，从库仅处理最终一致性读；dbresolver无法识别写语义SQL、不感知复制延迟、无自动故障剔除；需手动管理连接池、健康检查与延迟监控。
Go 语言里没有“开箱即用”的读写分离框架，所有生产级读写分离都建立在两个独立 *sql.DB 实例之上：一个连主库（masterDB），一个或多个连从库（slaveDBs）。强行用单个 sql.DB 配多个地址、或依赖 SQL 文本解析路由，上线后必出问题。
为什么不能只靠 GORM 的 dbresolver 插件自动切库
GORM v2 的 dbresolver 确实能根据事务状态自动路由，但它只解决“是否在事务中”这一层判断，无法识别 SELECT ... FOR UPDATE、INSERT ... SELECT 或带写语义的 CTE 查询。这类语句在从库会直接报错：ERROR 1290 (HY000): The MySQL server is running with the --read-only option。
- 它默认把所有非事务
SELECT发往从库，但业务里常有“强一致性读”需求（比如支付扣款前查余额），这时必须绕过 resolver，显式调用db.WithContext(context.WithValue(ctx, "force_master", true)) -
dbresolver不感知复制延迟，从库 lag > 5s 时仍照发请求，导致前端看到“刚提交就查不到” - 它的
Replicas列表是静态配置，节点宕机后不会自动剔除，需配合外部健康检查 +Resolver.ReplaceReplicas()手动刷新
如何初始化和管理多个 *sql.DB 实例并避免连接泄漏
每个库必须独立 sql.Open()，不能复用配置或浅拷贝指针——*sql.DB 是运行时状态对象，不是配置模板。
- 主库：
masterDB.SetMaxOpenConns(30)、masterDB.SetConnMaxLifetime(5 * time.Minute)、masterDB.SetWriteTimeout(2 * time.Second)，初始化后立刻masterDB.Ping()，失败直接 panic - 从库：
slaveDBs[i].SetMaxOpenConns(120)、slaveDBs[i].SetConnMaxLifetime(15 * time.Minute)、slaveDBs[i].SetReadTimeout(8 * time.Second)，首次读前做异步Ping()，超时则标记isHealthy = false - 每个实例都要单独
defer db.Close()，尤其在测试或 CLI 工具中容易漏掉；HTTP 服务里建议在shutdown阶段统一Close()
事务内混用主从库的典型错误现象和修复方式
最隐蔽的问题不是报错，而是数据不一致：事务里用 slaveDB.QueryRow() 查了旧值，再用 masterDB.Exec() 更新，结果基于过期快照做了错误决策。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
tx, _ := masterDB.Begin()后，又调slaveDB.QueryRow("SELECT ...")—— 这根本不是事务查询，是另一个独立会话 - 正确做法：事务内所有操作必须用
tx.QueryRow()、tx.Exec()，且tx只能来自masterDB.Begin() - DAO 层禁止封装
ReadDB()这类全局函数；若需复用逻辑，应接收db *sql.DB为参数，由上层决定传masterDB还是slaveDB
从库负载不均和延迟感知的实际落地要点
简单轮询或随机选从库，在真实集群中会导致 30%+ 流量打到高延迟或半死节点上。必须引入轻量状态管理。
- 维护一个
type Replica struct { DB *sql.DB LastLagSec float64 IsHealthy bool }切片，每 5 秒异步执行SHOW SLAVE STATUS或pg_replication_slots更新状态 - 每次读请求前过滤：
replicas = filter(replicas, func(r) bool { return r.IsHealthy && r.LastLagSec - 剩余节点按
LastLagSec倒序加权随机（lag 越小权重越高），而非纯随机 - 降级策略要明确：无健康从库时，
ctx.Value("consistency") == "eventual"则返回错误，"strong"则 fallback 到masterDB，但需记录告警
真正难的不是怎么连上从库，而是当主库写入后、从库还没追上时，你敢不敢让前端显示“处理中”，而不是硬切回主库暴露写库压力。这个边界，代码写不死，得靠业务指标卡住。
