fiber 的 c.context() 返回 *fasthttp.requestctx，非标准 context.context，须启用 enablecontext 并用 c.usercontext() 获取标准 context 才能用于 queryrowcontext 等；超时需手动 withtimeout + defer cancel。
直接说结论：Fiber 的 c.Context() 不是标准库 context.Context，不能直接传给 http.Client.Do 或 sql.DB.QueryContext 等函数；必须显式提取并转换为标准 context.Context 才能参与 Go 生态的超时/取消链路。
fiber.Ctx.Context() 返回的是 *fasthttp.RequestCtx，不是 context.Context
Fiber 基于 fasthttp，它的 c.Context() 方法返回的是 *fasthttp.RequestCtx 类型——这是 fasthttp 自己的上下文实现，和 Go 标准库的 context.Context 完全无关。如果你误把它当标准 context 传给 db.QueryRowContext(ctx, ...)，编译会直接报错：cannot use c.Context() (type *fasthttp.RequestCtx) as type context.Context。
常见错误写法：
func handler(c fiber.Ctx) error {
ctx := c.Context() // ❌ 这不是标准 context
row := db.QueryRowContext(ctx, "SELECT ...") // 编译失败
return nil
}
正确做法是用 Fiber 提供的 c.Context().Value(fiber.CtxKey) 或更稳妥的方式：从 c.Context() 获取底层标准 context（如果已配置）——但注意：默认情况下，Fiber 并不自动注入标准 context.Context。
如何在 Fiber 中获得真正的 context.Context？
Fiber v3 默认不绑定标准 context.Context 到请求生命周期。你需要主动启用或手动创建。两种主流方式：
- 启用
fiber.Config{EnableContext: true}：启动 app 时开启该选项后，c.Context()会自动携带一个标准context.Context，可通过c.Context().Value(fiber.CtxKey)取出（实际类型是context.Context），但更推荐直接用c.UserContext()——它是 Fiber v3 提供的专用方法，返回标准context.Context，且支持被中间件修改。 - 手动创建并注入：若未启用
EnableContext，可在 handler 开头用context.WithTimeout(c.Context().Value(fiber.CtxKey).(context.Context), 5*time.Second)——但前提是c.Context().Value(fiber.CtxKey)已存在，否则 panic。所以强烈建议统一启用EnableContext: true。
示例（推荐）：
app := fiber.New(fiber.Config{
EnableContext: true, // ✅ 必须开启
})
app.Get("/user/:id", func(c fiber.Ctx) error {
ctx := c.UserContext() // ✅ 返回标准 context.Context
id := c.Params("id")
user, err := fetchUser(ctx, id) // 可安全传入 QueryRowContext、Do 等
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
return c.Status(fiber.StatusGatewayTimeout).SendString("timeout")
}
return c.Status(fiber.StatusInternalServerError).SendString("error")
}
return c.JSON(user)
})
WithValue 传递请求元数据要避开字符串键
Fiber 支持用 c.Locals(key, value) 存储请求级数据（如用户 ID、traceID），但它和标准 context.WithValue 是两套机制：c.Locals 只在 Fiber 内部可用，无法穿透到 database/sql 或 net/http 的 context 消费侧。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
如果你想让下游函数（比如封装的 logRequest(ctx)）也能读取 traceID，必须用标准 context.WithValue 包装 c.UserContext()：
type traceKey struct{} // ✅ 自定义类型作 key，避免冲突
app.Use(func(c fiber.Ctx) error {
ctx := c.UserContext()
traceID := generateTraceID()
ctx = context.WithValue(ctx, traceKey{}, traceID)
c.SetUserContext(ctx) // ✅ 替换掉当前 ctx，后续 c.UserContext() 就带值了
return c.Next()
})
然后在业务 handler 中：
traceID, ok := c.UserContext().Value(traceKey{}).(string)
别用 "trace_id" 这种字符串当 key —— 多个包都这么写就会覆盖，且类型不安全。
超时控制必须靠 c.UserContext() + WithTimeout，不能只靠 fiber.Timeout 中间件
Fiber 的 fiber.Timeout 中间件只控制 handler 执行总时长，它会直接中断响应并返回 503，但不会向下游 I/O 操作发送取消信号。比如你数据库查询卡住 10 秒，fiber.Timeout 到点就返回 503，但 QueryRowContext 还在等 DB 响应，连接没释放，goroutine 泄露。
真正健壮的做法是：用 context.WithTimeout(c.UserContext(), 3*time.Second) 创建子 context，再传给 DB/HTTP 调用，并在 handler 结尾 defer cancel()：
ctx, cancel := context.WithTimeout(c.UserContext(), 3*time.Second) defer cancel() row := db.QueryRowContext(ctx, "SELECT ...")
这样 DB 驱动收到 ctx.Done() 后会主动中断连接，资源及时回收。Fiber 的 Timeout 中间件可作为兜底（比如防止 handler 逻辑死循环），但不能替代 context 级别的超时传播。
最容易被忽略的一点：Fiber v3 的 c.UserContext() 返回的 context 是由框架管理的，你调用 WithTimeout 后生成的新 context，其生命周期与 handler 绑定，但 cancel() 必须手动调用，否则 timer goroutine 会泄漏 —— 这和标准库行为完全一致，别以为 Fiber 会帮你 defer。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
