ctx.redirect必须传完整路径或绝对url，因其不补全路径，相对路径会按当前请求路径拼接导致错误；301/302需显式指定，漏写默认302；重定向前须先设cookie等header，且不可后续再写响应体。
ctx.Redirect 为什么必须传完整路径或绝对 URL
Fiber 的 ctx.Redirect 不做路径补全，它直接把第二个参数（状态码）和第一个参数原样塞进 Location 响应头。传相对路径如 "login" 或 "./dashboard"，浏览器会按当前请求路径拼接，结果可能是 https://example.com/api/v1/login 这种错误地址。
常见错误现象：本地开发时恰好跳对了，上线后 Nginx 或 CDN 前置导致路径基准变化，重定向就失效。
-
ctx.Redirect("/dashboard", 302)→ 正确：解析为根路径下的/dashboard -
ctx.Redirect("https://new.example.com", 301)→ 正确：绝对 URL，协议必须显式写出 -
ctx.Redirect("login", 302)→ 错误：会被当作子路径，比如从/api/auth发起，就跳到/api/auth/login
301 和 302 怎么选、为什么不能漏写状态码
不传状态码时 ctx.Redirect("/home") 默认发 302，这是临时重定向，浏览器不会缓存；而 301 是永久重定向，一旦被浏览器或 CDN 缓存，后续修改就很难生效——本地测试必须开无痕模式或清空缓存才能验证。
典型误用场景：
- API 版本迁移用 302：
app.Get("/v1/users", func(c *fiber.Ctx) error { return c.Redirect("/v2/users", 302) })→ 客户端反复请求旧地址，无法利用缓存提升性能 - SEO 迁移用 302 而非 301：
c.Redirect("https://www.new-site.com", 302)→ 搜索引擎不传递权重，新域名长期不被收录 - 想用 301 却漏写参数：
c.Redirect("/old", 301)写成c.Redirect("/old")→ 实际仍是 302，语义错位
重定向前设置 Cookie 或 Header 容易踩的坑
ctx.Redirect 只是快捷封装，底层调的是 ctx.Status().SendString() 并加 Location 头，它**不会中断后续执行**，也不会自动帮你设 Set-Cookie。
错误写法会导致 panic 或 Cookie 丢失：
-
c.Redirect("/home", 302); c.JSON(...)→ panic: “body already written” -
c.Redirect("/home", 302); c.Cookie(...)→ Cookie 不会发出，因为响应体已写完 -
c.Cookie(...); c.Redirect(...)→ ✅ 正确顺序：先写 Header/Cookie，再重定向
注意：Cookie 设置必须在 Redirect 调用之前完成，且要确保 Path、Domain 等字段匹配目标路径，否则浏览器可能拒绝发送。
StrictRouting 下重定向尾斜杠的通用中间件写法
Fiber 默认 StrictRouting: true，意味着 /users 和 /users/ 是两个路由。如果只注册了前者，后者访问就会 404 —— 但你不该关 StrictRouting，而该统一处理尾斜杠。
推荐中间件写法（放在所有路由前）：
app.Use(func(c *fiber.Ctx) error {
if strings.HasSuffix(c.Path(), "/") && c.Path() != "/" {
return c.Redirect(strings.TrimSuffix(c.Path(), "/"), 301)
}
return c.Next()
})
这个逻辑简单有效，但要注意两点：
- 必须用
return c.Redirect(...)，否则c.Next()还会继续执行后续 handler - 301 是有意为之：避免同一资源有两个 URL，利于 SEO 和缓存一致性
- 别在重定向后还调
c.Send或c.JSON，Fiber 不阻止你，但 HTTP 层会报错
真正复杂的地方在于：重定向不是“跳过去就完了”，它牵扯到缓存策略、客户端行为、Cookie 作用域、甚至前端 history.pushState 的兼容性。多数人只记得调 Redirect，却忘了它前面那行 c.Cookie 和后面那个 return 才决定成败。
