Go语言无法原生实现读写分离，因sql.DB是单数据源抽象，database/sql与驱动均不解析SQL语义，正则匹配前缀易误判SELECT FOR UPDATE等写语义查询，事务内混用主从库破坏ACID隔离性，主从库需独立连接池调优，GORM须用dbresolver插件并显式声明读写意图。
Go 语言本身不提供数据库读写分离能力，sql.DB 是单数据源抽象，强行拼接主从地址或依赖 SQL 文本解析路由，必然失败。
为什么不能用正则匹配 SQL 前缀判断读写
因为 database/sql 和 MySQL/PostgreSQL 驱动都不解析 SQL 语义——它们只把字符串原样发给服务端。你写的 "SELECT * FROM users FOR UPDATE" 在驱动眼里就是普通字节流，不会触发“这是写锁”的逻辑。
- 常见错误：用
strings.HasPrefix(sql, "SELECT")就发到从库，结果遇到SELECT ... FOR UPDATE、WITH RECURSIVE或带注释的/*+ read_replica */ SELECT，直接在从库报错：ERROR 1290 (HY000): The MySQL server is running with the --read-only option - ORM（如 GORM）生成的语句可能以
SELECT开头但实际执行写锁，无法靠前缀识别 - 大小写混用、子查询嵌套、SQL 注释包裹会让字符串匹配完全失效
- 事务内哪怕只调一次
QueryRow，如果发到从库，就破坏 ACID 中的隔离性
GORM v2 必须用 dbresolver 插件显式声明主从
gorm.Open 初始化时传一个 DSN 是不够的；必须注册 dbresolver 插件，并明确指定哪些是 sources（主库）、哪些是 replicas（从库）。
- 常见错误：只初始化一个
*gorm.DB，没调用db.Use(dbresolver.Register())，或者把主从 DSN 写反，导致INSERT打到从库报cannot execute INSERT in a read-only transaction - 主库连接池建议设低并发：
db.SetMaxOpenConns(20)、db.SetWriteTimeout(3 * time.Second) - 从库连接池可设更高：
db.SetMaxOpenConns(100)、db.SetReadTimeout(10 * time.Second) - 每个连接池都必须单独
db.Ping()校验连通性，别等第一次 query 才暴露问题
事务内所有操作必须绑定同一个 *sql.DB 实例
一旦调用 masterDB.Begin()，得到的 *sql.Tx 只能走主库连接。如果你在事务里误调 slaveDB.QueryRow()，等于开了两个独立会话，刚 INSERT 的数据在从库查不到，业务逻辑直接错乱。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 最容易踩的坑：封装了一个全局
ReadDB()函数，然后在事务函数里无意识调用它 - 正确做法是让事务上下文携带数据库意图，例如用
context.WithValue(ctx, dbKey, masterDB)显式透传主库实例 - GORM 中事务内所有操作默认走
sources（主库），哪怕你只写db.Transaction(func(tx *gorm.DB) error { return tx.First(&u).Error }) - 强一致读（如刚写完立刻查）需手动切库：
db.Clauses(dbresolver.Write).First(&u)或db.Session(&gorm.Session{AllowGlobalUnlock: true}).First(&u)
多个从库负载均衡要独立连接池 + 健康检查
轮询或随机选一个从库是最常见策略，但每个 *sql.DB 实例自带独立连接池，不能共用——主库和从库负载特征完全不同：主库写多、延迟敏感；从库读多、连接复用率高。
- 共用连接池会导致监控失真、熔断失效，甚至主库被从库慢查询拖垮
- 简单轮询可用
sync.Mutex+ 索引取模，但生产环境建议用sync.Map缓存后端健康状态，配合定时探测（http.Client设Timeout: 2 * time.Second） - 故障节点剔除后，轮询索引要重置，否则可能长期跳过有效节点
- 恢复逻辑别用“连续成功 3 次”，而用“最后一次成功时间 > 30s 前”，更稳
真正麻烦的不是怎么选从库，而是怎么让业务代码清晰表达“这个读必须强一致”——GORM 不做延迟补偿，MySQL 主从复制有毫秒到秒级延迟，你看到的“读不到最新数据”，大概率是业务没处理好读写时序。
