sql.open仅初始化连接池不建连，必须立即调用db.ping()或db.pingcontext()验证真实连通性；漏掉驱动导入、dsn特殊字符未编码、连接池参数设置不当等细节易致线上故障。
sql.Open 不是连上数据库，只是准备连接池；真连得靠 db.Ping() 或第一次 Query。别在每次请求里调 sql.Open，全局复用一个 *sql.DB 实例才是正解。
为什么 sql.Open 总是不报错，但查询却失败？
因为 sql.Open 只校验 DSN 格式和驱动注册是否成功，不发任何网络请求。常见现象：代码编译通过、err == nil，但后续 db.Query 报 dial tcp: i/o timeout 或 connection refused。
- 必须显式调用
db.Ping()（或更推荐的db.PingContext(ctx)）来验证真实连通性，且应在服务启动时做 - 漏掉驱动导入是高频原因：
import _ "github.com/go-sql-driver/mysql"缺了下划线或包路径写错，就会 panicsql: unknown driver "mysql" - DSN 中密码含
@、/等特殊字符时，必须用url.QueryEscape编码，否则解析失败且错误模糊
SetMaxOpenConns 和 SetMaxIdleConns 怎么设才不翻车？
默认值为 0（无限制），线上极易触发 Too many connections 或连接堆积。参数不是越大越好，得看数据库服务端上限和业务特征。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
db.SetMaxOpenConns(25)：建议设为 MySQLmax_connections的 70%～80%，例如 DB 侧是 151，则设 20～25 -
db.SetMaxIdleConns(10)：应 ≤MaxOpenConns，通常取其一半；设太高会导致空闲连接长期占着 DB 资源 -
db.SetConnMaxLifetime(5 * time.Minute)：强制连接定期重建，防 RDS/AWS 等云数据库因wait_timeout主动断连导致后续查询报connection reset by peer
DSN 字符串里哪些参数不能少？
MySQL 驱动对 DSN 解析敏感，少关键参数会引发时区错乱、时间解析失败等隐蔽问题。
-
parseTime=true：否则DATETIME字段扫进time.Time会是零值 -
loc=Local：避免默认 UTC 导致时间偏移（尤其日志、定时任务场景） -
charset=utf8mb4：支持 emoji 和四字节 UTF-8 字符，不加可能存入乱码 -
&是 URL 查询分隔符，不是 HTML 实体&；写成&会导致参数解析失败
事务中怎么避免连接泄漏和状态错乱？
事务必须用 *sql.Tx 对象执行全部操作，不能混用 *sql.DB 和 *sql.Tx。
- 所有
Query、Exec必须走tx.Query/tx.Exec，不能用db.Query - 必须显式调用
tx.Commit()或tx.Rollback()；忘记Rollback()会导致连接卡在事务中无法归还池 - 从
tx.Query得到的*sql.Rows也要rows.Close()，否则连接不会释放
真正难的不是连上，而是让连接池稳住、参数不漂移、错误不掩盖——尤其是 db.Ping() 放在哪、SetConnMaxLifetime 设多长、DSN 特殊字符怎么逃逸，这些细节一旦漏掉，问题往往压测才暴露。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
