Fiber框架无法通过配置项一键设置请求超时，必须在handler内用context.WithTimeout显式控制；fiber.Timeout中间件已废弃，ReadTimeout/WriteTimeout仅作用于TCP连接层，无法中断业务逻辑执行。
不能靠配置项一键设超时，必须在 handler 内用 context.WithTimeout 显式控制；fiber.Timeout 中间件已废弃，ReadTimeout/WriteTimeout 只管 TCP 层，不杀卡死的业务逻辑。
为什么 fiber.Timeout 和 fasthttp.Server.ReadTimeout 都不顶用
fiber.Timeout 是空壳中间件，v2.5+ 和 v3.x 全部标记为 deprecated，调用后既不设 deadline 也不 cancel ctx，压测时完全失效。而 fasthttp.Server.ReadTimeout 只约束“从 socket 读完完整请求头+体”的耗时，对 handler 里死循环、锁竞争、DB 查询卡住等场景毫无反应。它甚至无法中断一个正在等待下游 HTTP 响应的 http.Client.Do 调用。
常见错误现象：
- 设了
ReadTimeout: 1 * time.Second，但 handler 里time.Sleep(5 * time.Second)仍跑满 5 秒才返回 - 上传大文件时被直接切断，因为 body 还没读完就超时了
- 日志里全是
client disconnected，却找不到明确的 timeout 错误标识
单路由超时：用 context.WithTimeout 包裹 I/O 操作
这是最可控、最推荐的方式。关键不是“给整个 handler 设限”，而是把带超时的 ctx 传给每个可能阻塞的调用点。
立即学习“go语言免费学习笔记（深入）”；
实操要点：
- 必须在 handler 开头创建：
ctx, cancel := context.WithTimeout(c.Context(), 3*time.Second)，并defer cancel() - 所有下游调用必须显式使用该
ctx：如db.QueryRowContext(ctx, ...)、httpc.Do(req.WithContext(ctx))、redisClient.Get(ctx, key) - 不能只靠
defer cancel()—— 它不会自动中断 goroutine，得靠被调用方响应ctx.Done() - 别用
time.Sleep测试超时逻辑，它不响应 cancel；改用select { case
示例片段：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
app.Get("/user", func(c *fiber.Ctx) error {
ctx, cancel := context.WithTimeout(c.Context(), 2*time.Second)
defer cancel()
<pre class='brush:php;toolbar:false;'>var id int
err := db.QueryRowContext(ctx, "SELECT id FROM users WHERE name = ?", c.Query("name")).Scan(&id)
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
return c.Status(fiber.StatusGatewayTimeout).SendString("db timeout")
}
return c.Status(fiber.StatusInternalServerError).SendString("db error")
}
return c.JSON(fiber.Map{"id": id})})
全局或分组超时：用 middleware.TimeoutWithConfig，但必须填 Timeout
它能统一拦截并返回超时响应，但行为和你想象的不一样：它只标记 c.IsAborted() == true，不会终止当前 goroutine，也不会回滚已执行的操作。
必须注意：
-
Timeout字段不可省略或为 0，否则启动 panic：middleware.TimeoutWithConfig(middleware.TimeoutConfig{Timeout: 2 * time.Second}) - 按下游能力分组配置更合理：上传接口用
10 * time.Minute，API 接口用2 * time.Second - 超时后必须手动检查：
if c.IsAborted() { return nil }，否则后续逻辑仍会执行 - 所有 DB/HTTP 调用仍需用自己创建的带超时
ctx，不能依赖c.Context()—— 它的Done()和这个中间件无关
反向代理和外部 HTTP 调用的超时要单独配 Transport
Fiber 不是反向代理框架，若用 httputil.ReverseProxy 或 http.Client 调外部服务，超时必须落在 http.Transport 层，而不是靠 handler 级 context。
关键配置项：
-
DialContext：控制建连超时（如(&net.Dialer{Timeout: 3*time.Second}).DialContext） -
ResponseHeaderTimeout：等待响应头的最大时间，防 handshake 卡死 -
ReadTimeout：从连接读响应体的超时，防大 body hang 住 - 千万别用
context.WithTimeout包裹proxy.ServeHTTP—— 它不中断底层 TCP 流，只停 handler 执行
容易被忽略的一点：超时触发后，fasthttp 不会自动关闭连接。如果 handler 已开始写响应（比如已调 c.Status(200)），客户端会继续等 body 流完或断连，造成 P99 延迟虚高和连接池堆积。
