直接用 c.Send() 手动序列化并设 Content-Type，避免 c.JSON()/c.XML() 强制头；中间件统一包装响应结构体而非劫持响应流；用 c.Accepts() 分支返回不同格式，空 Accept 时可靠 fallback。
怎么让 Fiber 返回自定义结构体而不被自动加 Content-Type
Fiber 的 c.JSON() 和 c.XML() 会强制设置对应 Content-Type，但有些场景（比如返回纯文本协议、自定义 MIME 类型、或需要复用已有 header）你得绕过它。直接用 c.Status(200).Send() 是最可控的方式，前提是自己序列化好字节。
常见错误现象：c.JSON(map[string]string{"data": "ok"}) 后再调 c.Set("Content-Type", "application/vnd.myapi+json") —— 没用，JSON() 已经写死了头，后续 Set() 不会覆盖已发送的响应头。
正确做法：
- 用
json.Marshal()或xml.Marshal()手动序列化，再传给c.Send() - 手动调
c.Set("Content-Type", "...")，且必须在c.Send()前 - 如果要复用错误结构体统一格式，建议封装成方法：比如
WriteResponse(c *fiber.Ctx, status int, v interface{}) error，内部做 marshal + set + send
如何在中间件里修改最终响应体（比如加签名、包装外层字段）
不能直接改 c.Response().Body()，因为它是只读的；Fiber 底层用的是 fasthttp，响应体一旦写出就不可逆。必须在 handler 执行前“拦截”输出流——即用 fiber.New() 初始化时传入自定义 fasthttp.RequestCtx 的 Response.BodyWriter，或者更实际的做法：用中间件包装 c.Context() 并重写 Write() 方法。
关键限制：HTTP body 只能写一次，所以必须在 c.Next() 后捕获原始输出，再重新写入新内容。示例逻辑：
type responseWriter struct {
fiber.Ctx
body *bytes.Buffer
}
func (rw *responseWriter) Write(p []byte) (int, error) {
rw.body.Write(p)
return len(p), nil
}
// 中间件中：
body := &bytes.Buffer{}
c.Response().SetBodyStreamWriter(func(w *bufio.Writer) {
// 这里不能直接操作 c.Response().Body()，需用 stream 写入
})
// 更稳妥方式是用 c.Response().Body() 读取（仅当未写出时），但需确保 handler 没提前 write
实际推荐路径：让所有 handler 返回结构体，由顶层中间件统一包装（如 {"code":0,"data":{...}}），而不是试图劫持原始响应流——后者极易因并发或多次 write panic。
为什么 c.Status(200).JSON() 有时不生效或状态码被覆盖
因为 c.Status() 只设置状态码，不发送响应；真正触发发送的是 c.JSON()、c.Send()、c.SendString() 等写入方法。但如果这些方法之前已有其他写入（比如另一个中间件调了 c.SendStatus(401)），fasthttp 就不允许二次写入，会 panic 或静默丢弃。
典型踩坑点：
- 鉴权中间件写了
c.Status(401).SendString("no")却没return，后续日志中间件又调c.JSON()→ panic: “response already sent” - 多个中间件都尝试设
Status，但只有第一个写入响应体的才生效 -
c.Status(200)单独调用后没接任何 Send 方法，客户端收到的是 200 空响应（Fiber 默认 fallback）
安全写法：每次设状态后立即跟写入操作，并显式 return。例如：
if !valid {
return c.Status(400).JSON(fiber.Map{"error": "invalid input"})
}
return c.Status(200).JSON(data)
怎么让不同路由返回不同默认格式（JSON/XML/Plain）
Fiber 没有内置 content negotiation，但可以用 c.Accepts() 判断客户端期望类型，再分支处理。注意 c.Accepts() 返回的是匹配的 MIME 类型字符串，不是布尔值。
常见误用：if c.Accepts("application/json") { ... } —— 这个判断永远为真，因为浏览器请求头通常带 */*，Fiber 默认 fallback 就是 json。
正确判断方式：
- 用
c.Accepts("application/json", "application/xml", "text/plain")，它返回第一个匹配的类型（如"application/xml"） - 对
Accept: application/json, text/plain;q=0.9，它会返回"application/json" - 没匹配到时返回空字符串，可 fallback 到默认格式
示例：
accept := c.Accepts("application/json", "application/xml", "text/plain")
switch accept {
case "application/xml":
return c.XML(data)
case "text/plain":
return c.SendString(fmt.Sprintf("%+v", data))
default:
return c.JSON(data)
}
这个逻辑必须放在 handler 开头，且确保所有分支都有明确返回，避免遗漏 return 导致后续代码继续执行。
最易被忽略的一点：Accept 头可能为空（比如 curl -X POST 不带 -H），此时 c.Accepts() 返回空，fallback 必须可靠；另外，c.Accepts() 不解析 q-weight，只做简单前缀匹配，别指望它做精细协商。
