用 sql.db 实现读写分离需准备 masterdb 和 slavedb 两个实例，写操作走 masterdb，select 默认走 slavedb 但事务内必须全走 masterdb；连接池须分开配置，主库小连接池+短生命周期，从库大连接池+高复用；强一致性场景通过业务传 consistency=strong 强制走主库。
怎么用 sql.DB 实现读写分离的连接路由
Go 原生 sql.DB 不支持自动读写分离，必须自己在调用前决定用哪个数据库连接。核心不是换库，而是换 *sql.DB 实例 —— 你得准备至少两个：一个连主库（masterDB），一个连从库（slaveDB）。
常见错误是试图用单个 sql.DB 配置多个 DSN，或者幻想驱动能自动识别 SELECT / INSERT 并分流 —— 没有驱动这么做，SQL 解析不在 driver 层，也不该在。
- 所有写操作（
INSERT、UPDATE、DELETE、CREATE等）必须显式走masterDB - 读操作（
SELECT）默认走slaveDB，但要注意：事务内读必须走主库（否则可能读不到刚写的脏数据） - 如果用了
db.Begin()，不管里面是 SELECT 还是 UPDATE，整个事务都应绑定到masterDB
如何安全地在事务中避免误走从库
最容易踩的坑是：封装了一个 ReadDB() 函数返回 slaveDB，结果在事务里调它，导致 SELECT 去了从库，而同一事务的 UPDATE 在主库 —— 这根本不是事务，是两个隔离的会话。
正确做法是把数据库连接实例作为上下文透传，或通过 interface 抽象，让业务代码明确知道“当前在事务中”，从而绕过读写分离逻辑。
- 不要在事务函数内部调用
ReadDB()或WriteDB()；事务开始时就该确定用哪个*sql.DB - 可以用
context.WithValue(ctx, dbKey, masterDB)显式携带连接，后续操作从 ctx 取，而不是全局查 - 如果用 ORM（如 GORM），注意它默认的
Session或Transaction对象已绑定连接，此时再调db.Replica().First()是安全的；但自研封装容易漏掉这个绑定
database/sql 连接池要不要分开配置主从
要，而且必须分开。主库和从库的负载特征不同：主库写多、响应要求高、连接数通常少；从库读多、可容忍稍高延迟、连接池可以更大。
共用一个连接池不仅无法控制资源分配，还会让监控和熔断失效 —— 比如从库慢了，只该降权或切流，不该影响主库写入。
- 对
masterDB：设较小的SetMaxOpenConns(20)和较短的SetConnMaxLifetime(30m)，避免长连接堆积 - 对
slaveDB：可设更大的SetMaxOpenConns(100)，并开启SetMaxIdleConns(50)提升复用率 - 别忽略
SetConnMaxIdleTime(5m)，尤其在 Kubernetes 环境下，后端 Pod 重启会导致空闲连接失效，不设这个会卡住大量 idle conn
从库延迟导致读不到最新数据怎么办
这不是 Go 代码能解决的问题，但 Go 层要暴露可控开关。比如用户刚注册完立刻查个人资料，必须强制走主库，否则可能 404。
常见方案是加一个 consistency 参数，值为 strong（走主库）、eventual（默认走从库）。关键在于：这个参数得由业务逻辑判断，不能靠数据库自动推测。
- 登录态变更、支付结果、订单状态更新后立即查询，一律用
strong - 首页推荐、评论列表、历史浏览记录等，可用
eventual - 避免全局开关（如 “全站强一致性”），那等于放弃读写分离；也别用时间戳兜底（如 “写后 500ms 内走主库”），网络抖动会让它不可靠
真正难的不是分发逻辑，而是业务同学愿不愿意为每个读接口想清楚一致性要求 —— 这部分没法靠框架自动补全。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
