Go sql.DB连接池无通用最佳值，需结合DB能力、查询耗时、并发量综合设定；SetMaxOpenConns非并发上限而是连接总数上限，设过大易压垮DB；SetMaxIdleConns建议设为前者的1/2～1/3；SetConnMaxLifetime推荐30～60分钟；i/o timeout多因网络或DNS问题，需用db.PingContext检测；MySQL驱动须parseTime=true与loc=UTC成对使用；PostgreSQL生产环境必须启用SSL，推荐sslmode=require或verify-full；调参后务必通过DB端命令验证真实连接数。
Go sql.DB 连接池参数到底该设多大？
没有通用“最佳值”，必须结合数据库服务端能力、单次查询耗时、并发请求量三者看。盲目调大 SetMaxOpenConns 反而会压垮 MySQL 或 PostgreSQL，触发连接拒绝或锁等待。
-
SetMaxOpenConns不是并发数上限，而是连接句柄总数上限；超过后新请求会阻塞在sql.Open返回的*sql.DB上，直到有空闲连接释放 -
SetMaxIdleConns建议 ≤SetMaxOpenConns，且通常设为后者的 1/2～1/3；设太高会导致空闲连接长期占着 DB 端资源却不干活 -
SetConnMaxLifetime推荐 30～60 分钟（如30 * time.Minute），避免因 DB 侧主动 kill 长连接导致 Go 侧报driver: bad connection - 短平快服务（如 API 网关）可适当降低
SetConnMaxIdleTime（比如 5～15 秒），快速回收不用的连接；长任务型服务（如导出作业）需谨慎，频繁新建连接开销更大
为什么加了连接池参数还是出现 dial tcp: i/o timeout？
这个错误大概率不是连接池配置问题，而是网络层或 DNS 解析卡住。连接池只管复用已建立的连接，不负责首次建连超时控制。
-
sql.Open本身不建连，第一次db.Query或db.Ping才真正拨号；所以超时发生在执行阶段，而非初始化阶段 - 必须显式调用
db.PingContext(ctx)并传入带超时的context，否则默认无超时，可能卡死几秒甚至更久 - DNS 缓存失效、K8s Service DNS 解析慢、宿主机
/etc/resolv.conf配置不当，都可能导致i/o timeout；建议在容器内用dig或nslookup直接测目标 DB 域名 - 若用的是云数据库（如 AWS RDS、阿里云 RDS），确认安全组放行了对应端口，且 VPC 路由可达
MySQL 驱动里 parseTime=true 和 loc=UTC 怎么配才不出错？
这两个参数必须成对出现，否则 time.Time 字段反序列化会 panic 或返回零值。本质是驱动如何解释 MySQL 返回的时间字符串。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- MySQL 默认以系统时区存储
DATETIME，但不带时区信息；parseTime=true让驱动尝试转成time.Time，但没loc就不知道按哪个时区解析 - 推荐统一用
loc=UTC：在应用层做时区转换，避免 DB 侧时区变更引发数据错乱 - DSN 示例：
user:pass@tcp(127.0.0.1:3306)/db?parseTime=true&loc=UTC；注意&是 URL 中的 & 符号，不是 HTML 实体 - 如果业务强依赖本地时区（如报表展示），可在查询后用
time.In(loc)转换，不要靠驱动自动做
PostgreSQL 连接池要不要关掉 sslmode=disable？
生产环境必须开 SSL，除非你明确知道流量全程走内网且链路可信。PostgreSQL 驱动默认是 sslmode=prefer，看似安全，实则隐患很大。
立即学习“go语言免费学习笔记（深入）”；
-
sslmode=prefer表示“能连上就用 SSL，连不上就降级明文”——攻击者中间劫持后可强制让连接走明文，密码和数据全裸奔 - 正确做法是：
sslmode=require（最低要求）或sslmode=verify-full（需配 CA 证书）；配合sslrootcert=/path/to/ca.crt使用 - 注意：某些旧版 pgx 驱动（v3.x）不支持
verify-full，升级到 v4+ 或改用lib/pq驱动更稳妥 - 如果 DB 在同一 K8s 集群内，可用 Service Mesh（如 Istio）替代 TLS，此时可关 SSL，但得确保 mesh 的 mTLS 全局启用
最常被忽略的一点：连接池参数调完一定要观察 DB 端真实连接数，而不是只看 Go 应用日志。MySQL 查 SHOW PROCESSLIST，PostgreSQL 查 pg_stat_activity —— 池子设得再“合理”，DB 拒绝连接或连接数爆满，一切白搭。
