Fiber StrictRouting开启时/users与/users/是两个独立路由，直接访问后者会404；正确做法是在所有路由前添加中间件，对非根路径的尾斜杠请求301重定向至无斜杠版本。
StrictRouting 开启时，/users 和 /users/ 是两个独立路由，直接访问带尾斜杠的路径会 404 —— 这不是 bug，是 Fiber 的明确设计。别关 StrictRouting，否则 /users/123 可能被 /users 错误匹配，导致 c.Params("id") 拿不到值。
用中间件统一做 301 跳转（推荐）
把重定向逻辑抽成全局中间件，挂载在所有路由注册之前，比每个路由都手动注册 /xxx/ 更可靠、更易维护。
-
app.Use()必须放在app.Get()、app.Post()等路由注册之前，否则路径可能已被其他中间件改写或提前响应 - 判断条件要排除根路径：
c.Path() != "/"，否则http://host/会被错误重定向为http://host（无斜杠），触发协议降级或 400 - 用
strings.TrimSuffix(c.Path(), "/")处理路径，别手写path[:len(path)-1]，避免空字符串 panic 或双斜杠残留 -
c.Redirect()内部已终止 handler，不用再写return；但如果你用原生http.Redirect()，后面必须跟return
app.Use(func(c fiber.Ctx) error {
path := c.Path()
if strings.HasSuffix(path, "/") && path != "/" {
return c.Redirect(strings.TrimSuffix(path, "/"), fiber.StatusMovedPermanently)
}
return c.Next()
})
为什么不能关 StrictRouting？
关掉 StrictRouting: false 表面解决 404，实则埋下更隐蔽的路由歧义风险。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 假设你注册了
app.Get("/users", h1)和app.Get("/users/:id", h2)，关掉 StrictRouting 后，GET /users/123可能被/users匹配，c.Params("id")为空，后续逻辑崩掉 - Fiber 的参数提取严格依赖路径结构：
c.Params()只从占位符解析，c.QueryParam()只读 query string，混用就拿不到值 - 上线前必须同步检查 OpenAPI spec、前端 SDK、Postman 集合，确保全量使用无尾斜杠路径，否则重定向中间件会频繁触发
c.Redirect() 的执行边界要盯紧
c.Redirect() 看似简单，但常因“跳转后继续执行”引发 write to body after headers sent 错误。
立即学习“go语言免费学习笔记（深入）”；
- 它内部调用了
c.Status().Set("Location").Send()并自动return nil，所以你不需要也不应该再写return - 但如果你在中间件里写了
http.Redirect(w, r, "/login", 302)，没加return，后续c.Next()仍会执行，响应体二次写入必报错 - 重定向中间件里不要调
c.Next()—— 跳转已完成，再往下走既无意义，又可能污染状态
真正容易被忽略的是：这个中间件对查询参数完全透明，/users/?q=1 → /users?q=1 自动保留，但如果你在中间件里修改了 c.Request().URI() 或用了 ctx.Redirect() 以外的方式构造跳转地址，query 就可能丢失。别依赖“看起来能跑”，上线前用 curl 实测带参路径的跳转行为。
