重定向中间件必须显式 return，否则后续 handler 仍会执行；Fiber 不自动 abort，需手动中断控制流；StrictRouting 默认开启，/users 与 /users/ 视为不同路由；301 用于永久路径规范，307 保留原始请求方法和数据。
重定向中间件必须显式 return，否则后续 handler 仍会执行
在 Fiber 中写重定向逻辑，常见错误是调用 c.Redirect() 后没 return，导致后续 handler 继续执行，可能引发 write to body after headers sent 错误。Fiber 不像 Gin 那样自动 abort，也不像 Echo 那样隐式 return——它完全依赖你显式中断控制流。
典型翻车代码：
app.Use(func(c fiber.Ctx) error {
if strings.HasSuffix(c.Path(), "/") && c.Path() != "/" {
c.Redirect(strings.TrimSuffix(c.Path(), "/"), 301)
// ❌ 缺少 return，c.Next() 还会继续跑
}
return c.Next()
})
正确写法：
- 每次调用
c.Redirect()后必须紧跟return - 不要指望
c.Next()在重定向后“跳过”后续逻辑——它不生效 - 若用在全局中间件里，确保所有分支都有明确的 return 路径（包括重定向、放行、拒绝）
StrictRouting 开启时，/users 和 /users/ 是两个路由，别靠关掉它来“修重定向”
Fiber 默认 StrictRouting: true，这意味着 /users 和 /users/ 完全不互通。你只注册了 app.Get("/users", ...)，那访问 /users/ 就是 404，不是中间件没起作用，是根本没进路由匹配环节。
错误解法：fiber.New(&fiber.Config{StrictRouting: false}) —— 关闭后可能导致 /users/123 被 /users 拦截，c.Params("id") 拿不到值。
推荐做法：
- 加一层统一重定向中间件（放在
app.Use()最前） - 前端 SDK、OpenAPI 文档、内部调用全部约定使用无尾斜杠路径
- 若需兼容旧接口，显式注册两条：
app.Get("/users", ...)和app.Get("/users/", ...)
重定向状态码选 301 还是 307？取决于是否要保留原始 method 和 body
c.Redirect(path, status) 的 status 参数直接影响客户端行为：
-
301 Moved Permanently：浏览器会把后续 POST 改成 GET，且缓存重定向结果——适合路径规范（如去尾斜杠） -
307 Temporary Redirect：严格保留原始 method、body、headers——适合临时跳转（如 OAuth 登录页） -
302 Found行为类似 307，但部分老客户端可能降级为 301，不推荐用于 API 场景
示例：强制规范路径用 301；OAuth 授权流程中从 /oauth/authorize 跳转到 /login，应选 307，避免 POST 数据丢失。
ctx.Redirect() 返回 error，别忽略它
c.Redirect() 返回 error 类型，不是 void。虽然它内部只是封装了 http.Redirect 并返回 nil，但 Fiber 的 handler 签名要求你必须返回 error。忽略它或写成 _ = c.Redirect(...) 会导致编译失败或 panic。
正确姿势：
- 直接
return c.Redirect(...)—— 这是最简洁、最符合 Fiber 设计的方式 - 如果需要自定义响应头或日志，先设置再
return c.Redirect(...) - 别在
defer里调c.Redirect()——ctx生命周期已接近尾声，可能被复用
重定向本身不难，难的是它和 Fiber 的复用模型、StrictRouting、中间件生命周期咬合得非常紧。漏掉一个 return，或错估 StrictRouting 的影响，问题就会藏在上线后的偶发 500 或静默丢请求里。
