beego.InsertFilter必须在beego.Run()前注册，否则超时中间件无效；正确做法是在main()开头注册，使用ctx.SetTimeout()而非time.AfterFunc或context.WithTimeout，并通过ctx.Abort()处理超时响应。
beego.InsertFilter 必须在 beego.Run() 前注册
超时控制中间件不会生效，最常见的原因是注册时机错误。Beego 的过滤器链在 beego.Run() 启动服务时就已固化，之后调用 beego.InsertFilter() 完全被忽略——哪怕是在 init() 里晚于 beego.Run() 调用也不行。
正确做法是把超时过滤器注册放在 main() 函数最开头，或确保它在所有路由注册、配置加载之后、beego.Run() 之前执行：
复制AI写代码
1 2 3 4 5 6 7 8 9 10 11
func main() {
beego.InsertFilter("/*", beego.BeforeRouter, TimeoutFilter)
beego.Router("/", &MainController{})
// 其他配置...
beego.Run()
}
注意：TimeoutFilter 必须是签名 func(*context.Context) 的函数，且内部必须调用 ctx.Next()，否则请求链会中断。
超时必须用 ctx.SetTimeout()，不是 time.AfterFunc 或 context.WithTimeout
Beego 的上下文 *context.Context 提供了原生的超时控制接口 ctx.SetTimeout()，它会在指定时间后自动触发 ctx.Abort(503, "Service Unavailable") 并终止后续流程。这是唯一与 Beego 生命周期对齐的方式。
以下写法全是错的：
- 用
time.AfterFunc()手动 abort —— 可能重复 abort，也可能因 goroutine 延迟不生效 - 在过滤器里 new 一个
context.WithTimeout()但没传给 Controller —— Beego 的 ORM、Session 等模块不认这个新 context - 在
BeforeExec阶段才设 timeout —— 此时路由已匹配、Controller 已实例化，部分初始化逻辑（如Prepare()）可能已执行，超时失去意义
推荐写法（放在 BeforeRouter 阶段）：
复制AI写代码
1 2 3 4 5 6 7 8
func TimeoutFilter(ctx *context.Context) {
path := ctx.Request.URL.Path
if strings.HasPrefix(path, "/api/") {
ctx.SetTimeout(8 * time.Second)
} else if strings.HasPrefix(path, "/health") {
ctx.SetTimeout(2 * time.Second)
}
ctx.Next()
}
超时后 ctx.Output.Body() 不生效，必须用 ctx.Abort()
很多人在超时判断后直接调 ctx.Output.Body([]byte("timeout"))，发现响应体为空或状态码仍是 200。这是因为 Beego 的输出流在超时触发时已被框架接管并清空，Body() 调用无效。
超时处理的唯一合规方式是显式 ctx.Abort()：
复制AI写代码
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
var timeoutHandler = func(ctx *context.Context) {
ctx.SetTimeout(5 * time.Second)
ctx.Next()
// 检查是否已被 abort
if ctx.ResponseWriter.Status() != 0 {
return
}
// 若走到这里，说明未超时，继续
};
// 或更稳妥：在 AfterExec 中补漏（仅作日志，不改响应）
beego.InsertFilter("/*", beego.AfterExec, func(ctx *context.Context) {
if ctx.ResponseWriter.Status() == 503 {
log.Printf("Timeout on %s", ctx.Request.URL.Path)
}
})
关键点：ctx.Abort() 是原子操作，会立即终止当前 filter 链和 controller 执行；return 只退出当前函数，不能阻止后续逻辑。
并发场景下 SetTimeout 不影响其他请求，但需注意 panic 捕获
ctx.SetTimeout() 是 per-request 的，每个请求的超时互不干扰，无需加锁或全局 map 管理。但要注意：如果 Controller 的 Get() 方法里有未 recover 的 panic（比如空指针、数组越界），它会绕过超时机制直接崩溃整个 goroutine，导致响应卡死或返回 500。
建议在关键中间件中加一层 defer recover：
复制AI写代码
1 2 3 4 5 6 7 8 9 10 11 12 13
func SafeTimeoutFilter(ctx *context.Context) {
defer func() {
if r := recover(); r != nil {
log.Printf("Panic recovered in %s: %v", ctx.Request.URL.Path, r)
ctx.Abort(500, "Internal Server Error")
}
}()
ctx.SetTimeout(6 * time.Second)
ctx.Next()
}
真正的难点不在设 timeout，而在于 Controller 内部是否做了阻塞 I/O（如未设 timeout 的 HTTP 调用、无 limit 的 DB 查询），这些才是超时失效的根源。Beego 不会替你给第三方库加超时。
