应全局初始化*sql.DB并调用db.Ping()验证连通性，严格按驱动格式配置DSN（含SSL参数与URL编码），合理设置MaxOpenConns、MaxIdleConns和ConnMaxLifetime，并从环境变量安全加载配置，禁止每次查询新建连接池。
如何用 sql.Open 正确初始化数据库连接池
sql.Open 并不真正建立连接，它只是准备一个可复用的连接池句柄。常见错误是调用后立刻 db.Ping() 被忽略，导致后续查询时才暴露网络或认证问题。
- 必须显式调用
db.Ping()验证初始连通性，尤其在服务启动阶段 -
sql.Open的第二个参数（DSN）需严格遵循驱动格式，例如 PostgreSQL 要包含sslmode=disable或sslmode=require，MySQL 则注意parseTime=true是否启用 - DSN 中的密码若含特殊字符（如
@、/），必须用url.QueryEscape编码，否则解析失败且报错模糊（如invalid URL escape）
如何设置连接池参数避免超时与资源耗尽
默认连接池行为在高并发或长事务场景下极易出问题：连接数突增、空闲连接堆积、查询卡在 acquireConn 等待中。
- 用
db.SetMaxOpenConns(n)控制最大打开连接数，建议设为数据库服务器允许的最大连接数的 70%～80% -
db.SetMaxIdleConns(n)应 ≤MaxOpenConns，否则空闲连接无法被回收；生产环境通常设为MaxOpenConns / 2左右 -
db.SetConnMaxLifetime(time.Hour)强制连接定期重建，防止因数据库端主动断连（如 AWS RDS 的空闲超时）导致后续查询报connection reset by peer
如何安全传递数据库配置而不硬编码 DSN
把 DSN 写死在代码里或 config struct 中，会导致敏感信息泄露和环境切换困难。
- 从环境变量读取，例如
os.Getenv("DB_DSN")，并在启动时校验非空；避免用flag.String暴露密码到进程参数 - 若使用
viper，确保已调用viper.AutomaticEnv()并设置前缀（如viper.SetEnvPrefix("APP")），对应环境变量名如APP_DB_DSN - 密码字段永远不要打日志——哪怕是在 debug 模式下，检查所有
fmt.Printf、log.Printf是否误含db.dsn或结构体全量打印
为什么不能在每次查询前都 sql.Open 一次
这是初学者高频误操作：func getUser() { db := sql.Open(...); defer db.Close(); return db.QueryRow(...) }。后果严重且隐蔽。
立即学习“go语言免费学习笔记（深入）”；
- 每次
sql.Open都新建一个独立连接池，defer db.Close()只关闭池句柄，不立即释放底层连接，最终触发系统文件描述符耗尽（too many open files） - 连接池的复用、健康检测、空闲回收等机制全部失效，性能暴跌，且
Ping()和超时控制也失去意义 - 正确做法是全局初始化一个
*sql.DB实例（如放在main包变量或依赖注入容器中），整个应用生命周期内复用
