sql.Open仅初始化连接池而不建立实际连接，首次db.Query/Exec或显式db.Ping才触发连接；必须配置SetMaxOpenConns、SetMaxIdleConns和SetConnMaxLifetime；查询须用QueryContext/ExecContext配context超时；事务超时需在BeginTx时传入context。
sql.Open 不等于建立连接，只是初始化连接池
很多人以为 sql.Open 会立刻连上数据库，结果在后续 db.Query 或 db.Exec 时才爆出 dial tcp: lookup xxx: no such host 或超时，就是因为没搞清这个逻辑。sql.Open 只是创建并返回一个 *sql.DB 实例，它内部维护连接池，但不验证底层是否可达。
真正触发连接的是第一次执行查询或操作（比如 db.Ping()）。所以生产环境务必在初始化后加一次显式健康检查：
if err := db.Ping(); err != nil {
log.Fatal("failed to connect to database:", err)
}否则服务可能“启动成功”，却在第一个请求时崩掉。
SetMaxOpenConns、SetMaxIdleConns 和 SetConnMaxLifetime 必须配齐
只调 sql.Open 后放任默认值，高并发下极易打满数据库连接数或积累 stale 连接。三个参数不是可选的，是协同生效的硬性组合：
立即学习“go语言免费学习笔记（深入）”；
-
SetMaxOpenConns(n)：控制最多多少个活跃连接（含正在用 + 空闲中），设为 0 表示无限制——这很危险，MySQL 默认最大连接数常是 151，超了就拒绝新连接 -
SetMaxIdleConns(n)：空闲连接上限，建议 ≤SetMaxOpenConns，否则空闲太多反而拖慢 GC 和连接复用效率 -
SetConnMaxLifetime(d)：连接最长存活时间（如time.Hour），强制到期后关闭重连，避免因网络抖动、DB 重启导致的 stale 连接堆积
典型配置（适配中小流量 MySQL）：
db.SetMaxOpenConns(25) db.SetMaxIdleConns(20) db.SetConnMaxLifetime(1 * time.Hour)
context.WithTimeout 配合 QueryContext / ExecContext 才真能防卡死
原生 db.Query、db.Exec 没有超时控制，一旦数据库响应慢或网络中断，goroutine 就卡住，积压后直接 OOM。必须用带 context 的变体：
- 所有查询/写入操作优先走
db.QueryContext、db.ExecContext、db.PrepareContext - context 超时值要区分场景：读操作一般 3–5s，写操作可略长（如 10s），但绝不该用
context.Background()直接裸跑 - 注意：
context超时只会取消本次操作，不会关掉底层连接——连接池会自动回收或重建
错误示范：rows, _ := db.Query("SELECT ...")
正确写法：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel() rows, err := db.QueryContext(ctx, "SELECT ...")
事务里不能混用普通方法和 Context 方法
开启事务后拿到 *sql.Tx，它的 Query、Exec 等方法**没有 context 版本**（Go 1.22 仍如此）。这意味着：
- 如果想给事务加超时，必须在
db.BeginTx时传入 context：tx, err := db.BeginTx(ctx, nil) - 之后所有
tx.Query、tx.Exec等调用，都受该 ctx 控制（包括 commit/rollback） - 若误用
db.Begin()（无 context），再怎么在后续操作里套context都无效
容易被忽略的一点：事务的 context 一旦超时，tx.Commit() 或 tx.Rollback() 也会失败，并返回 context deadline exceeded，此时需按 error 类型判断是否已提交成功，不能简单重试。
