httplib.settimeout是最直接的接口级超时控制，需在.response()前链式调用，设connecttimeout和readwritetimeout两个time.duration参数，底层使用连接级deadline，非请求级超时。
httplib.SetTimeout 是最直接的接口级超时控制
Beego 的 httplib 模块封装了 HTTP 客户端逻辑，所有对外请求（如调用第三方 API）都走它。超时必须在发起请求前显式设置，否则用的是默认值：连接和读写各 60 秒。
常见错误是只设一个参数、或在 .Response() 之后才调 SetTimeout —— 此时请求早已发出，设置无效。
-
SetTimeout(connectTimeout, readWriteTimeout)两个参数单位都是time.Duration，比如10 * time.Second - 必须链式调用，在
.Response()或.ToJSON()前完成，例如：httplib.Post("https://api.example.com").Param("k", "v").SetTimeout(5*time.Second, 15*time.Second).Response() - 注意：这个超时是“连接建立 + 读响应体”的总耗时，不是单独的 connect 或 read timeout；底层用的是
net.DialTimeout和conn.SetDeadline，属于连接级 deadline，不是http.Client.Timeout那种请求级控制
Beego 内部 HTTP Server 的空闲与读取超时要单独配
如果你指的是 Beego 自己作为服务端接收外部请求时的超时（比如微信小程序调你的 /v1/user/login），那得改 beego.BConfig.Listen 下的 server 级配置，跟 httplib 无关。
不设这些，慢连接会一直占着 goroutine 和 fd，容易被 Slowloris 类攻击打满并发数。
-
beego.BConfig.Listen.HTTPTimeout已废弃，实际生效的是beego.BConfig.Listen.ReadTimeout和beego.BConfig.Listen.IdleTimeout -
ReadTimeout控制从 TCP 连接建立后，到读完全部 request header + body 的最大时间；设太短会导致大文件上传失败 -
IdleTimeout更关键：控制 keep-alive 连接空闲多久断开，默认 0（不限制），建议设为 ≤30s，防连接堆积 - 务必同步关掉 HTTP/2：在
main()中加beego.BConfig.Listen.EnableHTTP2 = false，否则IdleTimeout对 HTTP/2 连接不生效
ORM 数据库查询超时靠底层 *sql.DB 控制
Beego ORM 本身没有 QueryTimeout 配置项。它的查询超时完全依赖 Go 标准库的 *sql.DB 行为，而该行为由驱动层（如 mysql）和上下文控制。
你不能靠 orm.SetMaxIdleConns 或配置文件来设查询超时，那是连接池数量管理，和单次 SQL 执行时长无关。
- 真要控制单条 SQL 超时，必须用带 context 的方法，例如：
o.QueryTable("user").Filter("id", 123).One(&u, "name", "age")不行；得用o.QueryTable("user").Filter("id", 123).WithContext(ctx).One(&u)，其中ctx, _ := context.WithTimeout(context.Background(), 3*time.Second) - 连接池空闲连接释放时间（防止 MySQL
max_connections耗尽）要手动调：db, _ := orm.GetDB("default"); db.SetConnMaxIdleTime(60 * time.Second)，否则空闲连接可能永远不释放 - MySQL DSN 必须含
parseTime=true&loc=Local，否则 time 类型解析异常会导致连接卡死、无法归还池中，间接引发超时假象
别混淆 httplib 超时和 Controller 执行超时
有人试图在 BaseController.Prepare() 里用 context.WithTimeout 包裹整个业务逻辑，这是错的。Beego 的 Controller 生命周期不支持自动 cancel，ctx.Done() 不会中断正在跑的 goroutine，反而可能造成资源泄漏或 panic。
真正需要的是分层控制：httplib 控制出站请求，Server 配置控制入站连接生命周期，ORM Context 控制 DB 查询，三者互不替代。
最容易被忽略的一点：所有超时设置都依赖系统时钟精度和 GC 延迟。如果某次 GC STW 达到 10ms 以上，而你设了 100ms 超时，实际响应可能刚好卡在边界上失败 —— 这类问题不会报错，只会表现为偶发性超时，查日志也看不出原因。
