Go 的 sql.DB 自带线程安全连接池，无需手动实现；需合理配置 MaxOpenConns、MaxIdleConns、ConnMaxLifetime 和 ConnMaxIdleTime；应全局复用单个 sql.DB 实例，事务中必须使用 sql.Tx 对象操作。
Go sql.DB 本身已内置连接池，不需要手动实现
很多人一想到“并发访问数据库”，第一反应是自己写锁、建连接池、做限流。其实 sql.DB 在 Go 标准库中早已不是“单个连接”的封装，而是一个**带自动连接池的数据库句柄**。它默认支持并发调用 Query、Exec、Prepare 等方法，无需额外同步控制。
关键点在于：你拿到的 *sql.DB 是线程安全的，可被任意 goroutine 共享使用。它的连接池会在后台自动复用、新建、回收和关闭空闲连接。
必须显式配置 MaxOpenConns 和 MaxIdleConns
不设限会导致连接数爆炸——尤其在高并发或短连接场景下，数据库可能被撑爆。默认值（0）表示“无上限”，这在生产环境极其危险。
-
db.SetMaxOpenConns(n)：控制最多同时打开多少个底层数据库连接（含正在执行的 + 空闲的） -
db.SetMaxIdleConns(n)：控制连接池中最多保留多少个空闲连接（不活跃但未关闭） -
db.SetConnMaxLifetime(d)：强制连接在存活时间超过d后被关闭并重建（防长连接僵死） -
db.SetConnMaxIdleTime(d)：空闲连接最长保留时间（Go 1.15+ 才有，避免连接池积压陈旧连接）
典型配置示例：
立即学习“go语言免费学习笔记（深入）”；
db, _ := sql.Open("mysql", "user:pass@tcp(127.0.0.1:3306)/test")
db.SetMaxOpenConns(25)
db.SetMaxIdleConns(25)
db.SetConnMaxLifetime(5 * time.Minute)
db.SetConnMaxIdleTime(5 * time.Minute)不要在每次请求中调用 sql.Open
常见错误是把 sql.Open 放在 HTTP handler 或业务函数里，导致每来一次请求就新建一个 *sql.DB 实例。这不仅浪费资源，还会绕过连接池复用逻辑，迅速耗尽数据库连接数。
-
sql.Open不真正建连接，只做验证和初始化；真正的连接是在第一次db.Query等操作时惰性建立的 - 应全局复用一个
*sql.DB实例（比如放在包变量或依赖注入容器中） - 如果需要多套配置（如读写分离），才考虑多个
*sql.DB，但仍需各自独立配置连接池参数
事务内务必用 Tx 对象，别混用 db 和 tx
在事务中继续用 db.Query 而非 tx.Query，会导致查询脱离事务上下文，出现数据不一致或锁等待异常。
- 事务开始后，所有操作必须通过
*sql.Tx对象进行，包括Query、Exec、Prepare -
tx.Commit()或tx.Rollback()后，该tx对象不可再使用，也不可重复调用 - 事务超时或 panic 时，记得用
defer tx.Rollback()配合if err == nil判断来避免误回滚
正确用法片段：
tx, err := db.Begin()
if err != nil {
return err
}
defer func() {
if p := recover(); p != nil || err != nil {
tx.Rollback()
}
}()
_, err = tx.Exec("INSERT INTO users(name) VALUES(?)", "alice")
if err != nil {
return err
}
return tx.Commit()连接池参数不是“设了就完事”，它必须和你的数据库服务端最大连接数、业务 QPS、平均响应时间共同推算。一个没调优的 MaxOpenConns 比没有连接池更危险——它会让问题延迟暴露，直到某次流量高峰突然全链路超时。
