go中读写分离必须用两个独立*sql.db实例，主库处理写和强一致性读，从库仅处理最终一致性读；需显式路由、健康检查与延迟兜底，orm或sql解析无法自动识别读写语义。
Go 里没有“结合语言学习”实现读写分离这回事——读写分离是架构决策，不是语法糖或模型训练任务。所谓“高可用”，必须靠两个独立 *sql.DB 实例 + 显式路由 + 健康检查 + 延迟兜底，缺一不可。
为什么不能用 SQL 解析或 ORM 自动识别读写语义
database/sql 层根本不解析 SQL 字符串，驱动也只负责转发字节流。SELECT ... FOR UPDATE、INSERT INTO ... SELECT、带写锁的 CTE 查询，在驱动眼里全是普通 Query 调用。正则匹配“SELECT”开头就发从库，必然踩中 ERROR 1290 (HY000): The MySQL server is running with the --read-only option。
常见误判点：
- GORM 的
dbresolver只看方法名（Create/Find），不看 SQL 内容；Raw("SELECT ... FOR UPDATE")默认走从库，直接报错 - 事务内调用
slaveDB.QueryRow()，等于开了两个会话，刚INSERT的数据在从库根本看不到 - 注释、大小写、子查询嵌套会让字符串规则完全失效，比如
/* read: slave */ SELECT * FROM users驱动根本不识别
必须用两个独立 *sql.DB 实例并分开调优
主库和从库不是“换地址”，而是负载特征完全不同的服务端点：主库写多、延迟敏感、连接数少；从库读多、可容忍延迟、连接复用率高。共用连接池会导致监控失真、熔断失效，甚至主库被慢查询拖垮。
初始化时必须各自调用 sql.Open，再单独设置参数：
- 主库：
masterDB.SetMaxOpenConns(20)、masterDB.SetConnMaxLifetime(5 * time.Minute)、masterDB.SetWriteTimeout(2 * time.Second)，初始化后立刻masterDB.Ping()，失败直接panic - 从库：
slaveDBs[i].SetMaxOpenConns(100)、slaveDBs[i].SetConnMaxLifetime(10 * time.Minute)、slaveDBs[i].SetReadTimeout(8 * time.Second)，首次读前异步Ping()，超时则标记isHealthy = false - 每个
*sql.DB必须单独defer db.Close()，尤其 CLI 工具或测试中容易漏掉
事务内所有操作必须绑定同一个 *sql.Tx 实例
一旦调用 masterDB.Begin()，后续所有操作必须基于返回的 *sql.Tx 实例——tx.Query、tx.Exec 等方法底层仍走主库连接。如果你在事务里误调 slaveDB.QueryRow()，那就等于开了两个独立会话，刚写的数据在从库查不到，业务逻辑直接错乱。
典型错误现象：
- 事务里先
tx.Exec("INSERT ...")，再slaveDB.QueryRow("SELECT ...")，查到的是旧快照，导致余额扣减重复或库存超卖 - 封装的全局
ReadDB()函数在事务函数里无意识调用，等于绕过事务隔离 - 用
gorm.Session(&gorm.Session{Write: true})但没传入事务上下文，路由失效，仍走到从库
从库延迟必须由业务层兜底处理
GORM 或 database/sql 不感知复制延迟，Seconds_Behind_Master > 30 时照样转发请求。你看到的“刚提交就查不到”，大概率是业务没处理好读写时序。
可行方案：
- 强一致读（如支付前查余额）必须显式标记：
db.Clauses(dbresolver.Write).First(&user) - 对关键路径做延迟检测：定期执行
SHOW SLAVE STATUS，结合dbresolver.ReplaceReplicas()动态剔除 lag 过高的从库 - 主库降级读需限流：从库故障时，把读请求切到主库，但必须配
RateLimiter，否则主库被打爆
最常被忽略的一点：延迟不是网络问题，是 MySQL 复制线程本身的执行瓶颈。哪怕连接通、Ping 成功，Seconds_Behind_Master 也可能已到分钟级——这时候任何“自动切换”都只是把问题藏得更深。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
