Buffalo 的 Timeout 中间件不支持全局配置，需手动为特定路由封装超时逻辑：定义 WithTimeout 包装函数注入 context，并在 handler 中主动检查 timeout_ctx 实现超时控制。
Buffalo 的 Timeout 中间件不支持全局配置
Buffalo 没有内置的、可直接注册为全局中间件的请求超时控制机制。它的标准中间件栈（如 middleware.Automatic）里压根没有 Timeout 类型中间件，你无法像 Gin 那样用 r.Use(gin.Timeout(5 * time.Second)) 一键启用。
必须手动 wrap handler 并用 http.TimeoutHandler
Go 标准库的 http.TimeoutHandler 是唯一可靠的选择，但 Buffalo 不允许你直接替换底层 http.Handler；你得在每个路由 handler 外层手动包一层——这不是优雅的中间件，而是侵入式补丁。
- 在
actions/app.go里定义包装函数：func WithTimeout(h buffalo.Handler, d time.Duration) buffalo.Handler { return func(c buffalo.Context) error { // 注意：c.Response() 返回的是 http.ResponseWriter，但 TimeoutHandler 要求 *http.ResponseWriter // 所以必须用自定义 wrapper 或提前 abort // 更实际的做法是：只对特定高风险路由（如文件上传、第三方调用）加超时 ctx, cancel := context.WithTimeout(c.Request().Context(), d) defer cancel() c.Set("timeout_ctx", ctx) // 供后续 handler 主动检查 return h(c) } } - 在具体 handler 中主动判断：
func UploadHandler(c buffalo.Context) error { ctx := c.Value("timeout_ctx").(context.Context) select { case <-ctx.Done(): return c.Error(408, errors.New("request timeout")) default: // 正常处理逻辑 } return c.Render(200, r.JSON(map[string]string{"status": "ok"})) } - 不要试图在
App.Middleware.Before里统一注入context.WithTimeout：Buffalo 的 context 生命周期和 HTTP 连接生命周期不完全对齐，容易导致 goroutine 泄漏或超时失效
为什么不能用 net/http.Server.ReadTimeout 代替？
有人想在 app.go 启动时改 http.Server 的 ReadTimeout，这只能控制连接建立后读取 request header 和 body 的时间，对 handler 执行耗时完全无效。你看到的“超时”其实是连接被断开，客户端收到的是空响应或 connection reset，不是 408 错误。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
-
ReadTimeout：只管“读完请求头+体”的时间，单位秒，设太小会误杀大表单 -
WriteTimeout：只管“写完响应”的时间，不包含 handler 执行阶段 - 真正要控的是 handler 执行时长，必须靠
context.WithTimeout+ 显式检查
容易踩的坑：Buffalo 的 c.Request().Context() 不是 request-scoped
Buffalo 默认复用 http.Request 的 context，但它在中间件链中不会自动派生新 context。如果你在 Before 中调用 req = req.WithContext(...)，后续 handler 取到的仍是原始 context——除非你强制重设 c.Set("request_ctx", newCtx) 并在每个 handler 里手动取用。
最稳的方式是：只对明确需要超时保护的 endpoint 单独加 context.WithTimeout，别碰全局 context 注入。微服务场景下，这种粒度反而更可控。
