应使用 WithContext + context.WithTimeout 为每次查询显式设置超时，避免慢查询阻塞 goroutine；需封装统一超时方法并合理调优连接池参数，否则超时可能失效。
用 WithContext + context.WithTimeout 控制单次查询等待上限
GORM 本身不提供“全局查询超时”配置，所有超时必须显式传入 context。直接调用 db.Find() 没有超时机制，慢查询会一直卡住 goroutine 和数据库连接。
正确做法是在每次查询前构造带时限的 context：
-
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)—— 超时后返回context deadline exceeded错误 - 必须
defer cancel()，否则 context 泄漏，goroutine 无法被回收 - 传给 GORM：
db.WithContext(ctx).Find(&users)，GORM 内部会在 SQL 执行各阶段检查ctx.Done() - 注意：超时从
WithContext开始计时，不是从真正发 SQL 开始；若前面有预处理（如参数绑定、事务检查），也会计入
避免在循环里重复写 WithContext 的模板化封装
手动在每个 Find/First/Where 前加 context 容易遗漏，尤其多人协作时。推荐封装一个带默认超时的查询方法：
- 定义统一超时常量：
const defaultQueryTimeout = 1500 * time.Millisecond - 封装函数：
func QueryWithTimeout(db *gorm.DB, timeout time.Duration) *gorm.DB { ctx, _ := context.WithTimeout(context.Background(), timeout); return db.WithContext(ctx) } - 使用：
QueryWithTimeout(db, 2*time.Second).Where("id = ?", id).First(&user) - 不建议用全局 context（如
context.Background()）做默认值，因为无法取消；也不建议复用同一个 context 实例，会导致多个查询共享超时终点
SetConnMaxIdleTime 和 SetMaxIdleConns 不影响查询等待时间
这两个参数常被误认为能控制“查询排队等待”，其实它们只管连接池里的空闲连接生命周期：
-
SetMaxIdleConns(10)：最多保留 10 个空闲连接，超出的立即关闭 -
SetConnMaxIdleTime(45 * time.Second)：空闲连接在池中最多待 45 秒，之后被主动关掉 - 真正决定“查询是否要排队等待连接”的是
SetMaxOpenConns和当前已占用连接数；当所有连接都在用，新查询会阻塞在sql.DB.conn()内部，这个等待**不受 context 控制** - 所以必须同时调优：
SetMaxOpenConns要略大于你预期的最大并发查询数，否则即使加了WithContext，也会先卡在连接获取阶段，超时前根本到不了 SQL 执行
高并发下超时失效的典型场景与规避
即使写了 WithContext，仍可能发现超时没生效，常见于以下情况：
- 数据库连接池已满（
MaxOpenConns耗尽），新查询在获取连接时阻塞 —— 此时 context 还未进入 GORM，超时无效 - 事务未及时提交或回滚，导致连接长期占用，后续查询排队；GORM 的
Transaction默认不自动 commit，必须显式调用Commit()或Rollback() - 用了
db.Session(&gorm.Session{PrepareStmt: true})等会复用 prepared statement 的配置，但预编译语句缓存失效或重编译时可能引发隐式长等待 - MySQL 侧设置了过长的
wait_timeout（如 8 小时），而 Go 端未设SetConnMaxIdleTime，导致复用陈旧连接时报invalid connection，此时重试逻辑若没套 context，就会无限卡住
