gorm dbresolver不解析sql内容，仅按方法名和事务状态路由：create/update强制走主库，find/first默认走从库；select for update或insert select等特殊语句需显式加clauses(dbresolver.write)避免发往只读从库报错。
Go 里没有“多维度读写分离”这种开箱即用的抽象，所有稳定落地的方案都基于两个根本事实：主库和从库是语义不同的服务端点，GORM 的 dbresolver 只按方法名或事务状态路由，不看 SQL 内容、不感知延迟、不自动剔除故障节点。
为什么 dbresolver 不能识别 SELECT FOR UPDATE 或 INSERT SELECT
它硬编码了方法名映射：Create/Update 强制走主库，Find/First 默认走从库。但 SELECT ... FOR UPDATE 是读操作语法+写锁语义，INSERT INTO t SELECT ... 是写操作却以 SELECT 开头——这些在 dbresolver 看来只是普通查询，会发到从库，直接触发 MySQL 的 ERROR 1290 (HY000): The MySQL server is running with the --read-only option。
- 别指望正则匹配 SQL 前缀，ORM 生成的语句带注释、CTE、大小写混用，匹配必然漏判
-
Raw("SELECT ... FOR UPDATE")默认走从库，必须显式加.Clauses(dbresolver.Write) - 强一致性读（如扣款前查余额）不能依赖“默认路由”，得用
db.Clauses(dbresolver.Write).First(&u)或db.WithContext(context.WithValue(ctx, "force_master", true))
如何配置主库和多个从库并避免连接池错配
主库和从库不是“换地址”，而是负载特征完全不同的服务：主库写多、延迟敏感、连接数少；从库读多、可容忍延迟、连接复用率高。共用连接池参数会导致主库被慢查询拖垮，或从库连接耗尽。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 主库初始化后立刻
masterDB.Ping()，失败直接panic；从库用异步Ping()+ 超时标记isHealthy = false - 主库设
masterDB.SetMaxOpenConns(20)、SetWriteTimeout(2 * time.Second)；从库每个实例单独设slaveDBs[i].SetMaxOpenConns(100)、SetReadTimeout(8 * time.Second) -
AddSlave返回error必须检查，否则从库不可达时静默 fallback 到主库，日志无提示 - 每个
*sql.DB实例必须独立sql.Open()，绝不能浅拷贝指针或复用 DSN 配置
事务内混用主从库导致数据不一致的真实表现
最危险的不是报错，而是业务逻辑出错：事务里用 slaveDB.QueryRow() 查到旧值，再用 masterDB.Exec() 更新，结果基于过期快照做决策。MySQL 层面甚至不会报错，只默默返回陈旧数据。
- 一旦调用
masterDB.Begin()，后续所有操作必须基于返回的*sql.Tx实例，比如tx.QueryRow()、tx.Exec() - 封装的全局
ReadDB()函数在事务函数里无意识调用，等于开了第二个独立会话，刚写的数据在从库查不到 - GORM 的
db.Transaction()内部已绑定主库，但如果你在回调里调用了db.Session(&gorm.Session{ReadOnly: true}).Find()，仍可能走从库——必须确保整个事务链路不穿插任何从库调用
主从延迟下“刚提交就查不到”的业务兜底怎么做
GORM 和 dbresolver 不做任何延迟补偿，这是架构层必须面对的现实。复制 lag 在毫秒到秒级波动，业务代码得主动应对。
- 强一致性场景（如创建后立即跳详情页）必须用主库读，哪怕多花几毫秒
- 非关键路径可用“先查从库，查不到再查主库”的 fallback，但要控制重试次数和超时，避免雪崩
- 监控从库
Seconds_Behind_Master，lag > 5s 时主动剔除该节点，调用Resolver.ReplaceReplicas()刷新列表 - 不要依赖
context.WithTimeout包裹读操作来“等延迟过去”，timeout 后连接可能已释放，再取从库连接会失败
真正麻烦的从来不是怎么配通，而是那些没报错却悄悄错掉的逻辑——比如事务里一次无意识的从库查询，或者从库宕机后 fallback 到主库却没人发现流量突增。这些点没法靠框架自动兜住，得靠代码审查、连接池指标监控、以及对 MySQL 复制机制本身的敬畏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
