预热必须在main()中同步执行，因init()时DB/Redis未初始化易panic，goroutine异步执行则可能被主goroutine退出中断，导致连接未建满或泄漏。
必须在 main() 启动流程中同步完成预热，不能用 init() 或 goroutine 异步执行；否则连接池未就绪就触发查询，直接 panic 或连接泄漏。
为什么预热必须放在 main() 里、且不能异步
Go 的 init() 函数执行时，sql.DB 或 pgxpool.Pool 实例往往还没初始化——比如 db, err := sql.Open(...) 还没跑，此时调用 db.QueryRow() 就会触发 nil pointer dereference。同样，go preloadDB() 看似无害，但 http.ListenAndServe() 返回后主 goroutine 退出，后台预热可能被强制中断，导致连接只建了一半、指标显示“已预热”但实际 MinConns 未达标。
常见错误现象：panic: runtime error: invalid memory address or nil pointer dereference 堆栈指向预热函数内某次 db.Query()；或日志显示 “preloaded 12/50 connections”，之后再无输出。
- 正确顺序是：
InitDB()→preloadDBConnections()→http.ListenAndServe() - 若用了
wire或其他 DI 框架，确保preloadDBConnections()是显式调用，而非被自动 resolve 的依赖 - 超时控制必须加：
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)，超时后记录 warn 并设降级标记（如atomic.StoreBool(&dbReady, false)）
pgxpool 的 MinConns 预热是否足够？还要手动做吗
MinConns 确实会触发后台协程创建连接，但它只保证“连接已建立”，不保证“连接可用”——比如网络抖动、PostgreSQL 后端进程未响应、或认证失败时，createIdleResources() 可能静默跳过失败连接，最终池中活跃连接数仍低于预期。
所以生产环境必须叠加主动验证：
- 预热后立即执行一次轻量健康检查：
err := pool.Ping(ctx)，失败则 abort 启动 - 用
pool.Stat()校验AcquiredConns和IdleConns是否达到MinConns设定值 - 避免依赖默认行为：显式设置
MinConns: 10和MinIdleConns: 10（二者相等才能确保预热后全空闲）
MySQL / database/sql 连接池怎么手动预热
database/sql 没有内置预热 API，必须靠“触发式填充”：通过并发执行若干次空查询，迫使连接池新建连接直到达到 SetMaxIdleConns() 上限。
示例做法：
func warmupSQLPool(db *sql.DB, target int) error {
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
<pre class="brush:php;toolbar:false;">// 先确保配置已生效
db.SetMaxIdleConns(target)
db.SetMaxOpenConns(target)
// 并发执行空查询，填满空闲队列
var wg sync.WaitGroup
errCh := make(chan error, target)
for i := 0; i <p>}</p>
- 不要用
db.Ping()单次调用——它只建一个连接，无法填满池 - 并发数必须 ≥
target，否则部分连接永远进不了 idle 队列 - 注意
ConnMaxLifetime设置过短（如 30s）会导致刚预热完连接就被回收，需设为 5~30 分钟
预热时如何避免拖垮数据库
预热不是“越多越快”，而是要控制节奏和资源占用。一次性拉满连接池，可能触发 PostgreSQL 的 max_connections 限制，或 MySQL 的 max_connect_errors 封禁。
- 分批预热：每批 5 个连接，间隔 100ms，用
time.Sleep()或rate.Limiter - 加连接级超时：
db.SetConnMaxLifetime(10 * time.Minute)，防止长连接堆积 - 监控关键指标：预热后检查
pg_stat_activity中state = 'idle'的连接数是否匹配MinConns - 降级开关必须存在：若预热失败，跳过并记录，但允许服务降级启动（比如只读模式）
最易被忽略的一点：预热逻辑本身没有日志上下文，出错时只能看到 “failed to warm up”，根本不知道是 DNS 解析失败、密码错误，还是 pg_hba.conf 拒绝了连接。务必在每一步加带 traceID 的 debug 日志，并捕获底层错误类型（如 *net.OpError、*pq.Error）。
