答案是连接池参数配置不当——SetMaxOpenConns应设为MySQL max_connections的60%～80%，同步配置SetMaxIdleConns和SetConnMaxLifetime（2～5分钟），并穿透GORM错误封装识别原生错误码（如MySQL 1040、2013）以准确判断连接状态。
连接池报 Too many connections 怎么调参数
这根本不是 GORM 的错，是 SetMaxOpenConns 超过了数据库服务端的 max_connections 限制。MySQL 默认只有 151，你设成 200 就必然炸。
-
SetMaxOpenConns应设为数据库max_connections的 60%～80%，比如查出来是 200，就设 120～160 -
SetMaxIdleConns必须同步设，推荐为SetMaxOpenConns的 1/2 到 2/3（如 120 → 设 40～60） -
SetConnMaxLifetime必须配，云环境建议 2～5 分钟；设成 0 或time.Hour会导致连接僵死、DB 端积压idle in transaction - 漏掉
db.Session(&gorm.Session{}).Ping()，首请求才真正建连，这时候爆错会卡住整个服务启动
为什么 Ping() 成功但查询还报 connection refused
因为 Ping() 只验证连接池初始化是否成功，并不保证后续每次取连接都可用。网络抖动、防火墙超时、NAT 断连后，空闲连接可能已失效，但池子没主动清理。
- 必须配
SetConnMaxLifetime（如 3 分钟），强制连接到期重建 - 加定期健康检查：每 30 秒跑一次
db.Session(&gorm.Session{}).PingContext(ctx)并记录日志 - 别信
db.Error != nil—— 它可能是gorm.ErrRecordNotFound或主键冲突，不是连接问题
怎么准确识别“真连接断了”而不是业务错误
GORM 把底层错误全包成通用 error，必须穿透封装，看驱动原生错误码。否则重试逻辑会误判，把唯一键冲突当断连反复重试。
- PostgreSQL：断言为
*pq.Error，检查Code[0:2] == "08"（如"08006"表示连接失败） - MySQL：断言为
*mysql.MySQLError，检查Number()是否为2002（can't connect）、2013（lost connection）或1040（too many connections） - SQL Server：
*mssql.Error中State为"08"或Number为10053/10061
多数据源下连接池互相覆盖怎么办
常见写法是全局声明一个 var db *gorm.DB，然后反复 gorm.Open() 赋值——结果后开的库直接覆盖前一个，userDB 查到的是 logDB 的表。
- 每个库必须独立变量：
userDB、orderDB、cacheDB，各自调gorm.Open() - 驱动导入不能漏下划线：
import _ "gorm.io/driver/mysql"和import _ "gorm.io/driver/postgres" - DSN 里密码含
@、/、:、?必须用url.QueryEscape()编码，否则 DSN 解析提前截断，报错却是pq: password authentication failed
连接池本身不报错，它只是暴露配置不当的后果。最常被忽略的是：没设 SetConnMaxLifetime 却指望连接自动回收，或者用 db.Error 做连接判断——这两条在生产环境几乎必出问题。
