Beego ORM 本身不支持查询超时，必须通过 context.Context 传入 xxxContext 方法（如 AllContext、OneContext）并配合 DSN 中的 timeout/readTimeout/writeTimeout 参数协同控制。
Beego ORM 本身不支持查询超时，得靠底层 *sql.DB 控制
Beego ORM 没有提供类似 SetQueryTimeout 的接口，所有 SQL 执行最终都走 Go 标准库的 *sql.DB。所以超时必须在 DB 层设，而不是 ORM 层。常见错误是只调了 orm.RegisterDataBase 就以为万事大吉，结果慢查询卡住整个连接池。
关键点：
- 必须在
orm.RunSyncdb()或首次orm.NewOrm()之后，再调orm.GetDB("default")拿到真实*sql.DB实例 - 不能在
init()里就调GetDB，此时返回 nil 或 panic - 超时设置对已建立的连接立即生效，无需重启服务
SetConnMaxLifetime 和 SetConnMaxIdleTime 都不是查询超时
这两个方法管的是连接生命周期，不是单次查询耗时。比如设了 SetConnMaxIdleTime(30 * time.Second)，只是说空闲超过 30 秒的连接会被主动关闭；设了 SetConnMaxLifetime(3600 * time.Second)，只是说连接最多活 1 小时后强制重连——它们都不影响一条 SELECT ... WHERE ... 执行 5 分钟还不返回的问题。
真正要防查询卡死，得用上下文（context.Context）传入执行链：
o.Raw(sql).Prepare().ExecContext(ctx, args...)o.QueryTable("user").Filter("name", "x").OneContext(ctx, &u)- 所有带
Context后缀的方法才支持超时控制
必须显式用 context.WithTimeout 包裹 ORM 操作
Beego ORM 的常规方法（如 One()、All()、Insert()）默认无超时，一旦 DB 响应慢或锁表，goroutine 就一直挂着。解决方式是统一改用 xxxContext 方法，并传入带 timeout 的 context。
示例：
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
err := o.QueryTable("order").Filter("status", "pending").AllContext(ctx, &orders)
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
// 处理超时
}
}
注意：
- 别漏掉
defer cancel()，否则 context 泄漏 - 超时时间建议设为 P99 RT 的 2～3 倍，比如业务平均响应 800ms，可设 2.5s
-
Raw()查询也必须用ExecContext/QueryRowContext，不能用Exec()
DSN 缺少 timeout 参数会放大超时风险
MySQL DSN 中没加 timeout=3s&readTimeout=3s&writeTimeout=3s，即使代码层用了 context，驱动层仍可能在 TCP 握手、DNS 解析、网络丢包时卡住更久。
推荐 DSN 写法：
user:pass@tcp(127.0.0.1:3306)/dbname?charset=utf8&parseTime=true&loc=Local&timeout=3s&readTimeout=3s&writeTimeout=3s
特别注意：
-
timeout控制连接建立阶段，readTimeout/writeTimeout控制数据收发阶段 - 三者值建议一致，避免某一段无保护
- 若用 Redis 缓存做 fallback，也要给
redis.DialReadTimeout等参数设值，否则缓存层也会拖累整体超时判断
真正难处理的是那些已经进入 MySQL 执行队列、但迟迟不出结果的查询——context 超时只能让 Go 层断开，MySQL 还在跑。这类问题得靠数据库侧的 max_execution_time 配合应用层超时双保险。
