GORM连接池无ConnWaitTimeout，必须用context.WithTimeout控制借连接超时，否则排队请求会无限等待；需配合SetMaxOpenConns等参数协同防雪崩。
gorm连接池没有 ConnWaitTimeout，得靠 context 控制借连接超时
Go 标准库 database/sql 的连接池本身不提供“等待获取连接的超时时间”参数（即没有类似 ConnWaitTimeout 的配置项），GORM 作为上层封装更不会额外暴露这个能力。你看到的超时行为，实际由两层控制：底层 sql.DB 的阻塞等待 + 上层业务代码用 context.WithTimeout 主动中断。
为什么不能只设 SetMaxOpenConns 就完事
即使你已合理设置了 SetMaxOpenConns 和 SetMaxIdleConns，当所有连接都在使用中，新请求仍会排队等待空闲连接。若此时无连接释放，goroutine 就卡在 db.QueryContext 或 db.First 等调用里——它不会自动失败，而是无限等下去，直到连接被归还或进程退出。
- 典型现象：
db.First(&u)卡住几十秒甚至几分钟，pprof显示 goroutine 停在runtime.gopark，堆栈含database/sql.(*DB).conn - 根本原因：没传
context.Context，或传了但没设 timeout/cancel - 错误做法：试图在
gorm.Config或db.DB()上找 “wait timeout” 字段——它不存在
正确做法：所有数据库操作必须带带超时的 context
必须把超时逻辑下沉到每次查询/事务调用，而不是寄希望于连接池自动拒绝排队请求。这是 Go 生态的标准实践，也是唯一可靠方式。
- 普通查询：
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second); defer cancel(); db.WithContext(ctx).First(&user) - 事务内操作：在
db.Transaction()外层套 context，或在事务块内每个操作都显式传ctx - 全局兜底：可封装一个带默认 timeout 的
DB方法，比如db.Timeout(2 * time.Second).First(&u)（需自行扩展） - 注意：超时后 error 是
context.DeadlineExceeded，不是数据库错误，别误判为 SQL 执行失败
配合连接池参数才能真正防住排队雪崩
单靠 context 超时只能让单个请求及时失败，但如果连接池长期满载、大量请求反复排队又超时重试，依然会拖垮服务。必须和连接池参数协同：
-
SetMaxOpenConns要对齐 MySQL 的max_connections，避免 DB 层直接拒连（报ERROR 1040: Too many connections） -
SetMaxIdleConns和SetConnMaxLifetime必须配对设，否则空闲连接僵死，有效连接数持续下降，加剧排队 - 上线前用
db.Stats()观察WaitCount是否持续上涨 —— 这是排队已成常态的明确信号
最易忽略的一点：超时 context 必须在每次调用时显式传入，GORM 不会自动继承或 fallback 到某个全局 timeout。漏一次，就可能埋下一个静默卡死点。
