不能直接替换*sql.DB，因为其底层连接和状态共享， abrupt Close()会导致查询中断、事务回滚、连接泄漏；必须采用渐进式接管：预热新池、原子切换指针、旧池限流退场、确保事务与连接在切换前完成。
数据库连接池升级时为什么不能直接替换*sql.DB
直接用新配置新建一个*sql.DB，然后把旧连接池Close()掉，会导致正在执行的查询被中断、事务回滚、连接泄漏——因为*sql.DB不是原子替换对象，它背后是共享的底层连接和状态。Go 没有“热替换连接池”这种内置机制，所有连接都绑定在旧实例上，新实例无法接管活跃连接。
常见错误现象包括：sql: database is closed报错频发、HTTP 接口偶发 500、后台 Job 突然卡住不写数据。根本原因不是代码逻辑错，而是连接生命周期没对齐。
- 旧连接池关闭后，已获取但未归还的
*sql.Conn会 panic - 事务中使用的
db.Begin()返回的*sql.Tx仍指向旧连接池，Commit()可能失败 - 连接池参数（如
SetMaxOpenConns）变更后，必须等所有旧连接自然释放，否则新参数不生效
如何让新连接池真正“接棒”老连接池
核心思路不是“替换”，而是“渐进式接管”：新连接池先预热建连，老连接池逐步退场，期间所有业务代码仍走统一入口（比如封装后的GetDB()函数），由该入口控制路由逻辑。
- 定义一个线程安全的
atomic.Value，存放当前生效的*sql.DB指针 - 启动新连接池时，先调
db.PingContext()验证可用性，再用atomic.StorePointer()切换指针 - 老连接池不立刻
Close()，而是调db.SetMaxOpenConns(0)+db.SetMaxIdleConns(0)，阻止新连接分配，只等现有连接归还 - 加一个后台 goroutine 定期检查
db.Stats().Idle和db.Stats().InUse，当InUse == 0后再调db.Close()
注意：db.Close()本身不阻塞，但必须确保没有 goroutine 正在调用db.Query或db.Exec——否则会 panic。
立即学习“go语言免费学习笔记（深入）”；
sql.Tx和sql.Conn在升级期间怎么处理
事务和显式连接不能跨连接池迁移，这是硬限制。如果你的代码里用了db.Begin()或db.Conn()，就必须在连接池切换前完成它们。
- 禁止在连接池升级窗口期内开启新事务；可在入口层加一个全局开关
var upgrading atomic.Bool，Begin()前先if upgrading.Load() { return err } - 已有
*sql.Tx必须等Commit()或Rollback()完成后才允许升级开始 - 显式
*sql.Conn建议全部改用context.WithTimeout(ctx, 30*time.Second)包裹，避免因连接池关闭卡死 - 如果用了
db.Prepare()，注意*sql.Stmt绑定的是创建它的*sql.DB，切换后需重建
上线前必须验证的三个细节
很多团队卡在最后一步：以为连接池换了就万事大吉，结果线上查不到数据、慢查询暴增、甚至连接数翻倍。
- 确认
db.Stats().WaitCount在切换后是否持续上升——说明新连接池建连慢或配置不合理（比如net.DialTimeout太短） - 检查日志里有没有
driver: bad connection或connection refused，这往往是因为新连接池的 DSN 里漏了parseTime=true或loc=UTC等关键参数 - 用
pprof抓取/debug/pprof/goroutine?debug=2，确认没有 goroutine 卡在database/sql.(*DB).conn里——那是连接池关得太急的典型痕迹
真正的平滑不在代码换得有多快，而在旧连接是否彻底释放、新连接是否稳定承接、中间是否有不可观测的空窗——这些点不验，升级就是赌运气。
