Fiber没有传统路由钩子，所谓“钩子”实为中间件+Next()控制的前置/后置逻辑：前置在c.Next()前执行，后置必须在c.Next()返回后操作，defer不可靠。
什么是Fiber的路由钩子？它不是中间件
Fiber 的 Use、Get 等方法注册的函数，常被误称为“钩子”，但 Fiber 本身没有传统意义的“路由钩子”（如 Express 的 pre/post 钩子）。它只有中间件（middleware）和处理器（handler），而真正的生命周期控制点藏在中间件链顺序和 Next() 调用时机里。
你无法像 Laravel 那样写 beforeRoute 或 afterRoute，必须靠中间件位置 + 条件判断 + 手动控制流向来模拟。
-
Use()注册的中间件对所有匹配路由生效（包括子路径），适合全局前置逻辑 -
Get("/user", middleware, handler)中插入的中间件只对这一条路由生效，且在 handler 前执行 - 想实现“类似 post-hook”，只能在 handler 内部手动调用日志、清理或响应后操作——因为 Fiber 不提供
onResponseEnd这类回调
如何在 handler 执行前后插入逻辑？靠中间件位置和 Next()
这是最常用也最容易出错的方式。关键在于：中间件是否调用 Next()，以及调用时机。
比如你想统计某接口耗时，并在 handler 执行后记录状态码：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
app.Get("/api/data", func(c *fiber.Ctx) error {
start := time.Now()
// 前置逻辑：记录开始时间、校验权限等
if err := checkAuth(c); err != nil {
return err
}
// 必须调用 Next()，否则 handler 不会执行
if err := c.Next(); err != nil {
return err
}
// 后置逻辑：此时 handler 已返回，c.Response().StatusCode() 可读
log.Printf("req=%s status=%d dur=%v", c.Path(), c.Response().StatusCode(), time.Since(start))
return nil
}, handlerFunc)
- 这个中间件必须放在
handlerFunc之前，否则c.Next()会跳过它 -
c.Next()是同步阻塞调用，handler 返回后才继续执行后续代码 - 注意：如果 handler panic 或直接
c.SendStatus(500)后没 return，后置逻辑可能不执行——务必确保 handler 总是显式返回
为什么不能依赖 defer 实现“后置钩子”？
初学者常写：
app.Get("/test", func(c *fiber.Ctx) error {
defer log.Println("after handler") // ❌ 危险！
return c.SendString("ok")
})
这看起来像后置钩子，但实际不可靠：
-
defer在函数返回时执行，而 Fiber 的 handler 函数返回 ≠ HTTP 响应已写出。如果中间件链中上游有 panic、超时或连接中断，defer仍会执行，但此时c.Response().StatusCode()可能还是 0 或旧值 - 更严重的是：Fiber 内部可能复用
fiber.Ctx实例，defer里的闭包若捕获了未清理的状态（如临时 buffer、锁），会在下一次请求中引发数据污染 - 真正安全的“后置”操作，必须在
c.Next()返回之后、且确认 handler 已完成响应写入的位置做
替代方案：用自定义 ResponseWriter 包装？不推荐
有人尝试通过替换 c.Context().Response().BodyWriter() 来拦截响应体，但这违反 Fiber 设计哲学：
- Fiber 的
Ctx不暴露底层http.ResponseWriter，强行反射或 hack 会失去版本兼容性 - 响应体可能已被压缩（gzip）、分块（chunked）或流式写出，包装 writer 极易破坏协议格式
- 绝大多数场景（日志、指标、审计）只需状态码、路径、耗时——这些在
c.Next()后都能安全获取，无需碰 body
真有响应体修改需求（如统一加字段），应该在 handler 内部处理，或用 c.JSON() 封装层，而不是试图 hook 到 write 阶段。
复杂点在于：Fiber 的生命周期粒度只到“请求进入 → 中间件链 → handler → 响应写出”，没有细分到“响应头写出后”或“body flush 完毕”。如果你的业务强依赖这类精确时机，得考虑换用原生 net/http 或支持更细粒度 hook 的框架。
