最常见原因是重定向后未return，导致后续handler继续执行并重复写响应体；ctx.Redirect仅设状态码和Location头，不自动终止链路，必须手动return。
中间件里调用 ctx.Redirect 为什么没跳转
最常见原因是重定向后还执行了后续 handler，导致响应体被重复写入。Fiber 的 ctx.Redirect 只设置状态码和 Location 头，并不自动终止链路——它和 ctx.JSON() 一样，只是写响应的一部分。一旦你调了 ctx.Redirect()，再调 ctx.Send() 或 ctx.Render()，就会 panic 报错 failed to write body: http: superfluous response.WriteHeader call。
正确做法是：重定向逻辑完成后立刻 return，不碰 c.Next()：
app.Use(func(c *fiber.Ctx) error {
if c.Path() == "/old" {
c.Redirect("/new", 301)
return nil // ✅ 必须 return，否则继续执行会出错
}
return c.Next() // ✅ 放行才调 Next
})
如何统一处理带尾斜杠的路径重定向
Fiber 默认开启 StrictRouting: true，所以 /users 和 /users/ 是两个不同路由。直接注册两条路由虽可行，但更干净的做法是加一层中间件做 301 重定向，避免客户端缓存错误路径。
- 只对 GET/HEAD 方法做重定向（其他方法如 POST 不该被重定向）
- 检查路径是否以
/结尾且长度 > 1（排除根路径/） - 用
301而非302，确保搜索引擎和浏览器缓存新路径 - 注意重定向目标要去掉末尾斜杠，且保持协议、host、query 不变
示例：
app.Use(func(c *fiber.Ctx) error {
path := c.Path()
if c.Method() == "GET" && len(path) > 1 && strings.HasSuffix(path, "/") {
cleanPath := strings.TrimSuffix(path, "/")
c.Set("X-Redirected", "true")
c.Redirect(cleanPath + c.QueryString(), 301)
return nil
}
return c.Next()
})
重定向前设 Cookie 或 Header 为什么无效
ctx.Redirect 本身不设置任何 Cookie，也不修改响应头；它只是快捷封装了 ctx.Status().SendString() 加 Location 头。如果你在 Redirect 之后才调 c.Cookie()，那 Cookie 根本不会发出去——因为响应已经写出，Header 已锁定。
必须把 Cookie、Header 设置放在 Redirect 调用之前：
c.Cookie(&fiber.Cookie{
Name: "session_id",
Value: "abc123",
Path: "/",
HTTPOnly: true,
})
c.Redirect("/home", 302)
return nil
容易忽略的一点：Fiber 的 Cookie 方法默认不设 MaxAge，若要让 Cookie 在浏览器中持久化，得显式传 MaxAge: 3600 等值；否则关掉标签页就丢了。
为什么重定向中间件在某些路由下不生效
执行顺序决定一切。app.Use() 注册的中间件按代码顺序从上到下执行，而路由级中间件（如 app.Get("/x", mw, h)）只对该路由生效，且在全局中间件之后、handler 之前运行。
典型问题：
- 把重定向中间件写在
app.Use(cors.New())后面 → CORS 中间件可能已提前返回 OPTIONS 响应，重定向根本没机会触发 - 把重定向中间件写在
app.Static()之后 → 静态文件中间件已匹配并返回 200，后续中间件全跳过 - 重定向逻辑里用了
c.Params()或c.BodyParser()→ 这些方法依赖路由匹配结果或请求体解析，而重定向应在最外层做，别等路由匹配完再判断
建议把路径规范化类中间件（如去斜杠、大小写归一）放在所有其他中间件最前面，靠近 app.Use() 开头位置。
重定向不是“写个 URL 就完事”的操作；它是 HTTP 协议层面的状态变更，涉及缓存、客户端行为、响应生命周期三个维度。最容易被绕过的点是：你以为 redirect 是“跳走”，其实它只是“写了头+体”，剩下的全靠你控制流程和时机。
