不能在 Fiber 中间件中直接修改 response.data 字节流，因其为只读且可能未序列化；应通过封装 Success/Fail 等响应函数并在业务层显式调用实现统一格式，而非依赖中间件事后修补。
中间件里不能直接改 response.data 字节流
很多人想在 Fiber 中间件里拿到 c.Response().Body()，然后 json.Unmarshal → 修改结构 → json.Marshal 再写回去。这不可行：Fiber 的 response.Body() 是只读字节切片，且多数情况下尚未序列化（尤其你没调 c.JSON() 之前）。强行覆盖会破坏底层 buffer，甚至 panic。
真正能统一格式化的时机，是在你决定「要返回什么」那一刻——也就是调用 c.JSON()、c.Status().JSON() 或类似方法时。中间件的职责不是事后修补，而是提前拦截并接管输出逻辑。
- 别在中间件里解析已序列化的 JSON 字符串（它可能根本没生成）
- 不要依赖
c.Response().StatusCode()判断是否该格式化——状态码可能还没设，或已被后续逻辑覆盖 - 最稳妥的方式：用自定义响应函数替代裸
c.JSON()，再通过中间件注入上下文标记（比如c.Locals("api_response", true)），但实际封装仍放在业务层
@api_response 装饰器思路在 Fiber 里不成立
Fiber 是 Go，没有 Python 那种函数装饰器语法。所谓「视图装饰器」在 Go 里只能靠闭包包装 handler，但这样会导致路由注册变冗长，且无法自动捕获 panic 或未处理错误。
更现实的做法是：把统一结构封装成一个可复用的响应函数，并强制团队在 API 路由中显式调用它。例如：
func Success(c *fiber.Ctx, data interface{}) error {
return c.Status(fiber.StatusOK).JSON(map[string]interface{}{
"code": 0,
"msg": "ok",
"data": data,
"timestamp": time.Now().UnixMilli(),
})
}
<p>func Fail(c *fiber.Ctx, code int, msg string) error {
return c.Status(code).JSON(map[string]interface{}{
"code": code,
"msg": msg,
"data": nil,
})
}- 所有 API handler 必须用
Success(c, user)或Fail(c, 400, "参数错误")，而不是c.JSON(user) - 这个模式不依赖中间件，但需要代码规范约束；配合 linter（如
revive）可检查是否误用裸c.JSON - 若需动态开关（如 dev 环境跳过
timestamp），用全局配置变量 + 函数选项模式比中间件更清晰
errorhandler 无法覆盖所有错误路径
Fiber 的 app.Use(func(c *fiber.Ctx) error { ... }) 是普通中间件，不处理 panic；而 app.SetErrorHandler() 只捕获由 c.SendStatus()、c.Status().SendString() 等触发的错误，对未 catch 的 panic 或手动 return errors.New(...) 无效。
要真正兜底，必须组合两层：
- 顶层 recover 中间件：用
defer/recover捕获 panic，调用Fail(c, 500, "server error") - 全局错误处理器：
app.SetErrorHandler()处理 Fiber 自身抛出的错误（如路由未匹配、body 解析失败） - 业务异常仍需显式抛出并由 handler 捕获——Fiber 不像 FastAPI 那样有内置 exception handler 注册机制
常见漏点：c.BodyParser(&v) 失败时返回 error，但如果你没检查就继续执行，后续可能 panic 访问空指针；必须写 if err != nil { return Fail(c, 400, "解析失败") }。
为什么 after_request 钩子在 Fiber 里不存在
Fiber 没有类似 Flask 的 after_request 钩子。它的生命周期控制集中在 ctx.Next() 执行前后，以及 app.Use() 和 app.Get() 的顺序上。想实现“响应后处理”，唯一可行路径是：在所有路由 handler 结束后，用一个终级中间件检查 c.Response().StatusCode() 并重写 body —— 但这仅适用于你**确定所有 API 都走 c.JSON() 且未提前 return** 的场景。
这种做法风险极高：
- 静态文件、健康检查、Swagger 页面也会被套壳，导致前端无法解析
- 如果某个 handler 先调
c.SendString("raw")再c.JSON()，后者会失败（body 已提交） - Content-Type 可能被覆盖，前端收不到
application/json
结论：别试图用中间件“统一格式化”——Fiber 的设计哲学是显式优于隐式。把结构定义清楚、函数封装好、团队约定执行，比硬塞进中间件更稳定、更易调试。
