sql.open仅初始化连接池管理器而非建立真实连接，真实连接发生在首次db.query、db.exec或db.ping()时；必须立即调用db.ping()验证连通性，正确配置dsn编码、parsetime=true与loc=local、setmaxopenconns≤数据库max_connections×0.8且setmaxidleconns≤前者，全局复用*sql.db并显式close。
sql.Open不是建连接，是建连接池管理器
调用 sql.Open 不会立刻连数据库，它只注册驱动、解析 DSN、初始化一个连接池管理器。真实连接发生在第一次 db.Query、db.Exec 或显式 db.Ping() 时。
常见错误是忽略 db.Ping()，结果服务启动成功，但首条查询才暴露出密码错、网络不通或 DNS 解析失败——这会让故障发现延迟到业务请求进来之后。
- 必须在应用启动阶段调用
db.Ping()，并校验返回 error；超时建议设为 5–10 秒（用context.WithTimeout包一层） - DSN 中含特殊字符（如
@、/、:）必须用url.QueryEscape编码，否则解析失败报错模糊，例如invalid URL escape "%xx" - PostgreSQL 驱动需显式加
sslmode=disable或sslmode=require；MySQL 驱动若读写TIMESTAMP字段，必须带parseTime=true&loc=Local
SetMaxOpenConns 和 SetMaxIdleConns 容易 panic
SetMaxIdleConns 值必须 ≤ SetMaxOpenConns，否则 Go 1.12+ 会直接 panic，错误信息是 "max idle conns exceeds max open conns"。这不是 warning，是 runtime crash。
典型误配：db.SetMaxOpenConns(5) 后跟 db.SetMaxIdleConns(10) → 立即退出；或者只设 SetMaxIdleConns 没设 SetMaxOpenConns → 后者默认为 0（无限制），空闲连接池实际不可控，还可能触发数据库 Too many connections。
- 先设
SetMaxOpenConns，再设 ≤ 它的SetMaxIdleConns；生产环境推荐比例为MaxIdleConns = MaxOpenConns × 0.5 - 值不能拍脑袋：MySQL 默认
max_connections=151，PostgreSQL 默认max_connections=100，SetMaxOpenConns建议设为数据库该值的 70%～80% - 设太大不等于性能好——连接数压过 DB 承载能力，会导致大量
context deadline exceeded或connection refused
SetConnMaxLifetime 不是保活，是强制换新
SetConnMaxLifetime 的作用是“这个连接从创建起，最多活这么长时间，到期就关掉”，它不发任何 SQL，也不检测连接是否还通。很多团队误以为它能防断连，结果线上仍频繁出现 connection reset by peer 或 read: connection timed out。
真正起作用的是数据库侧的空闲超时（如 MySQL 的 wait_timeout=28800）和中间件（如 RDS Proxy、ProxySQL）的连接驱逐策略。Go 层面只能靠定期重建连接来规避。
- 推荐值：30–60 秒；太短导致频繁建连开销大，太长容易撞上 DB 侧超时
- 注意：它和
SetConnMaxIdleTime（Go 1.15+）不同，后者控制空闲连接最长待多久，两者可共存，但语义不重叠 - 如果你用的是 AWS RDS 或阿里云 PolarDB，它们默认空闲超时是 300–600 秒，
SetConnMaxLifetime设成 300 秒以内更稳妥
全局复用 *sql.DB，别在函数里 sql.Open
每个 sql.Open 调用都会新建一个独立连接池，defer db.Close() 只关闭句柄，底层连接不会立即释放。高频新建 + 关闭会快速耗尽文件描述符，报 too many open files，且所有连接池参数、健康检测、空闲回收机制全部失效。
典型反模式：func GetUser(id int) (*User, error) { db := sql.Open(...); defer db.Close(); return db.QueryRow(...) } —— 这种写法在压测中 QPS 上不去、CPU 却很低，因为线程全卡在 acquireConn 等连接。
- 正确做法：定义包级变量
var db *sql.DB，在main()或initDB()中初始化一次，整个生命周期复用 -
db.Close()必须显式调用，在main()结束前或收到SIGINT/SIGTERM时执行；不能依赖 GC，否则进程退出前连接仍占用 DB 资源 - 如果用依赖注入（如 wire、fx），把
*sql.DB作为 provider 注入，避免跨包裸引用
MaxIdleConns ≤ MaxOpenConns），且和数据库服务端行为深度耦合（比如 wait_timeout、SSL 配置、时区解析）。最容易被忽略的是 DSN 编码、parseTime 和 loc 的配合，以及 db.Ping() 的调用时机——这些地方出问题，往往表现为偶发性、难复现的连接失败，而不是一眼能看出的 panic。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
