Go的sql.DB连接池安全依赖正确配置：SetMaxIdleConns必须≤SetMaxOpenConns，否则panic；后者应≤数据库max_connections×0.8，前者为其1/2～2/3；SetConnMaxLifetime设30s～5分钟主动轮换连接；必须db.Ping()验证且配parseTime=true&loc=Local。
Go 的 sql.DB 连接池没有“安全连接”概念，只有正确配置的连接池才可能安全——配错 SetMaxOpenConns 和 SetMaxIdleConns 会直接 panic 或静默截断请求，不是慢，是崩。
SetMaxOpenConns 和 SetMaxIdleConns 必须满足大小关系
这两个值不是独立调优项，违反约束会立即失败：
-
SetMaxIdleConns(10)但SetMaxOpenConns(5)→ 运行时 panic，错误是"max idle conns exceeds max open conns" -
SetMaxIdleConns(20)但SetMaxOpenConns(50)→ 合法，空闲连接最多留 20 个 - 只设
SetMaxIdleConns(10)没设SetMaxOpenConns→ 默认MaxOpenConns = 0（无限制），极危险，可能打爆数据库
生产环境建议：SetMaxOpenConns ≤ 数据库 max_connections × 0.8（如 MySQL 默认 151，设 120 就已偏高）；SetMaxIdleConns 设为前者的 1/2～2/3（如 120 → 60）。
SetConnMaxLifetime 不是保活，是主动换新
它不会发心跳、不检测连接状态，只是强制连接用满指定时间后关闭，下次再借就是新连接：
- 设为
0表示永不过期 → 容易遇到i/o timeout或connection reset by peer（尤其在 RDS、ProxySQL、SLB 后） - 设太短（如
1 * time.Second）→ 频繁握手，CPU 和延迟双升 - 推荐值：30 秒～5 分钟。API 类服务用 30s，批处理长事务可放宽到 3～5 分钟
- 注意：它只对已归还到池中的连接生效，正在执行
Query或Exec的连接不受影响
sql.Open 后必须立刻 db.Ping()，且不能只靠它做健康检查
sql.Open 只解析 DSN、注册驱动，不建真实连接；db.Ping() 才真正拨号并验证连通性：
- 漏掉
db.Ping()→ DSN 写错、DB 未启动、网络不通等问题全被掩盖，直到第一个业务查询才暴露，日志里全是context deadline exceeded -
db.Ping()成功 ≠ 连接池健康：它只测一个连接，不校验空闲连接是否已失效（比如 DB 主动 kill 了 sleep 连接） - 线上
readiness probe别只用db.Ping()，应模拟真实路径，例如db.QueryRow("SELECT 1").Scan(&i)
MySQL 驱动下 parseTime=true 和 loc=Local 必须配对用
只要表里有 DATETIME/TIMESTAMP，且 Go 代码要正确读写时间，就必须加这俩参数：
- 不配这个，
time.Time字段查出来可能是零值或 panic，尤其在连接池后问题更隐蔽——因为不同连接可能用不同时区解析时间，结果不一致 - 典型错误：只加
parseTime=true，结果查出的time.Time的Location是 UTC，但业务逻辑默认按本地时区处理，导致时间偏移 8 小时 - DSN 示例：
user:pass@tcp(127.0.0.1:3306)/db?parseTime=true&loc=Local；若部署在 UTC 服务器但需东八区时间，loc=Asia%2FShanghai更稳妥（需 URL 编码）
连接池参数本身不加密、不认证，所谓“安全连接”实际依赖 TLS 配置（如 DSN 加 tls=true 或自定义 mysql.Config），但那是另一层事——池子配错，TLS 再严也没用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
