ctx.redirect默认发送302状态码实现临时重定向，需传入完整路径或绝对url，显式指定301才为永久重定向；注意url编码、cookie设置顺序及避免重复写响应体。
使用 Ctx.Redirect 做 302 临时重定向最简单
绝大多数场景下，你只需要调用 ctx.Redirect 即可完成跳转，它默认发 302 状态码，浏览器会自动跳转到目标 URL。注意：第二个参数是状态码，不传则为 302，不是 301。
常见错误是误以为不传状态码会“自动选最合适的”，结果线上流量被缓存导致调试困难；或者把路径写成相对路径（如 "./login"），而 Fiber 要求必须是完整路径或绝对 URL（含协议）。
-
ctx.Redirect("/dashboard", 302)→ 跳转到同站 /dashboard（推荐用于登录后跳转） -
ctx.Redirect("https://example.com", 301)→ 永久跳转到外部域名（SEO 敏感场景慎用） - 避免
ctx.Redirect("login", 302)—— 这会被解析为当前路径下的子路径，不是根路径
需要 301 永久重定向时显式传参
Fiber 不区分“重定向类型”，全靠你传的状态码决定行为。301 和 302 的语义差异完全由客户端（尤其是搜索引擎爬虫）解释，框架只负责发对应 HTTP 状态头。
典型误用：在 API 版本迁移中用 302 重定向旧接口，结果客户端缓存失效、反复请求；该用 301 时却漏写参数，导致重定向不可缓存。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 版本迁移示例：
app.Get("/api/v1/users", func(c *fiber.Ctx) error { return c.Redirect("/api/v2/users", 301) }) - 注意：301 一旦被浏览器/CDN 缓存，本地测试需清空缓存或用无痕模式验证
- 不要依赖中间件自动补状态码——Fiber 的
Redirect方法不会帮你做任何推断
重定向前修改响应头或设置 Cookie 需手动处理
ctx.Redirect 是个快捷封装，底层调用的是 ctx.Status().SendString() 并附带 Location 头。它**不会中断后续执行**，也不会阻止你提前写 Header 或 Cookie。
容易踩的坑是：在 Redirect 后还调用 ctx.JSON 或 ctx.Send，导致 panic（“body already written”）；或者想设 Cookie 却忘了重定向本身不携带 Cookie 设置逻辑。
- 正确做法：先设 Cookie，再 Redirect：
c.Cookie(&fiber.Cookie{Name: "session_id", Value: "abc", Path: "/"})→c.Redirect("/home", 302) - 错误写法：
c.Redirect(...); c.JSON(...)—— 必然报错failed to write body: http: superfluous response.WriteHeader call - 如果要加自定义 Header（如
X-Redirect-From），必须在Redirect前调用c.Set("X-Redirect-From", "/old")
重定向目标含动态参数时注意 URL 编码
当重定向地址里拼接用户输入（比如查询参数、路径段），不编码会导致 400 错误或跳转失败。Fiber 不做自动编码，Redirect 接收的字符串原样塞进 Location 头。
典型问题：重定向到 /search?q=hello world，空格未编码 → 浏览器收到非法头 → 直接拒绝跳转并显示空白页。
- 用
url.PathEscape或url.QueryEscape手动编码：c.Redirect("/search?q=" + url.QueryEscape(q), 302) - 路径参数用
url.PathEscape，查询参数用url.QueryEscape，别混用 - 不要依赖前端 JS 做跳转兜底——服务端重定向失败时，用户可能卡在白屏，且无错误提示
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
