sql.open仅初始化db结构体，不建立实际连接；首次query/exec才拨号，须用pingcontext探测连通性，并配置合理连接池参数及超时控制。
sql.Open后连接没建好？别信它会自动连
Go 的 sql.Open 只是解析 DSN、初始化 sql.DB 结构体，**根本不发任何网络包**。你看到的“连接成功”，其实是假象。真正拨号发生在第一次 db.Query 或 db.Exec 时——这时候卡住，才是真超时。
所以光调 sql.Open 没用，必须主动探测：
- 立刻跟一句
db.PingContext(ctx)，ctx带 5 秒超时，失败就 panic 或重试 - 别用
db.Ping()，它没超时控制，可能永久挂起 - 如果用的是 MySQL，DSN 必须含
parseTime=true&loc=Local，否则时间字段读出来是零值或时区错乱
SetMaxOpenConns 和 SetMaxIdleConns 怎么设才不崩库
默认值就是生产事故温床：SetMaxOpenConns 是 0（无限制），SetMaxIdleConns 是 2。高并发下瞬间拉几百连接，数据库直接拒绝新连接。
合理配置要结合你的 DB 实例规格和业务峰值 QPS：
-
SetMaxOpenConns(20)：MySQL 小型实例建议 10–30，别贪大；设为 0 等于裸奔 -
SetMaxIdleConns(10)：空闲连接留够复用，但别太多，否则连接池里堆着一堆快过期的旧连接 -
SetConnMaxLifetime(60 * time.Second)：强制连接最多活 60 秒，防 MySQL 的wait_timeout断连后还留在池里 -
SetConnMaxIdleTime(30 * time.Second)（Go 1.15+）：比老版靠SetMaxIdleConns+ 被动等待更干净，空闲超 30 秒就主动关掉
每次 Query 都得套 context.WithTimeout
连接池健康 ≠ 查询不卡死。慢 SQL、网络抖动、中间件静默丢包，都会让 db.Query 挂住。Go 的 database/sql 所有执行方法都支持 Context，这是唯一靠谱的单次操作超时方案。
HTTP handler 里别写 db.Query(sql)，改成：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
rows, err := db.QueryContext(r.Context(), sql)
后台任务自己控超时：
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)- 用完立刻
cancel()，避免 goroutine 泄漏 - MySQL 驱动 v1.7+ 才完整支持 context.Cancel 中断执行中语句；老版本只能中断等连接阶段
db.Close() 不是可选项，是退出前必做动作
sql.DB 不是连接本身，是连接工厂。GC 只回收结构体内存，**完全不关底层 TCP 连接**。漏掉 db.Close() 的后果很实在：进程退出时连接还占着，DB 端满屏 Sleep 状态连接，下次启动可能因端口被占或连接数满失败。
常见错误写法：defer db.Close() 放在 init 函数里——db 还在被其他 goroutine 用，就提前关了。
正确姿势：
- main 函数末尾显式调
db.Close() - 或配合
signal.Notify捕获os.Interrupt，做优雅关闭 - IoTDB、MongoDB 等非 SQL 数据库同理，客户端实例的 Close 方法必须手动调
最易被忽略的一点：连接池参数不是设一次就完事。压测时若发现连接数暴涨或 QPS 上不去，优先怀疑 SetMaxOpenConns 和 SetMaxIdleConns 是否与后端能力错配，而不是急着加机器。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
