Fiber路由需工程化分层：根路由挂全局中间件，Group承载业务前缀与权限，子路由专注路径/方法/参数；混用致404、中间件漏执行或版本失控。
Fiber 路由不是“写完就能用”，而是必须按工程化分层明确职责：根路由只做协议/全局中间件，分组承载业务域前缀与权限边界，子路由专注路径+方法+参数绑定——混用层级必然导致 404、中间件漏执行或版本逻辑失控。
app.Use() 和 app.Group() 别放错位置
全局中间件（如日志采样、CORS、请求体限制）必须挂 app.Use()，它对所有路径和所有 HTTP 方法生效；而 app.Group("/api") 是独立路由树节点，只组织子路由结构，不自动注入任何行为。
-
app.Use("/api", logger)→ 错误：这不是挂到 /api 下，而是匹配所有以 /api 开头的路径（包括 /api/v1/users、/api/static/logo.png），且会重复执行多次（每个方法都注册一份） -
app.Use(logger)→ 正确：全量请求统一采样，不依赖路径前缀 -
api := app.Group("/api"); api.Use(auth)→ 正确：鉴权只作用于 /api/* 下的所有路由，不影响 /health 或 /metrics -
api.Use("/v1", versionCheck)→ 错误：Group 的Use()不接受路径前缀参数，该写法会 panic
API 版本控制不能只靠 Group 前缀
单纯用 app.Group("/v1") 和 app.Group("/v2") 只能物理隔离路径，无法支持「同一 URL 根据 Accept 或 API-Version 头动态分流」这类真实场景。Fiber 的基数树在注册时就固化了路径，运行时不会跳转节点。
- 想让
GET /users同时支持 v1/v2？不能靠app.Get("/users", handler)+ if 分支——这破坏了路由语义，Swagger 也无法标注版本 - 正确做法是：先用中间件提取版本号，存入
c.Locals["version"]，再由 handler 内部调用对应 service 层逻辑 - 示例中间件：
func versionMiddleware(c fiber.Ctx) error { ver := c.Get("API-Version") if ver == "" { ver = c.QueryParam("version") // 兜底 query } c.Locals["version"] = ver return c.Next() }然后在api.Use(versionMiddleware)后注册统一api.Get("/users", usersHandler) - 注意：该中间件必须放在 Group 内注册，否则污染非 API 路由（如 /health）
StrictRouting=true 下尾斜杠必须显式处理
Fiber 默认 StrictRouting: true，/users 和 /users/ 是两条独立路由。线上环境绝不能关掉它来“省事”，否则 /users/:id 会被 /users 错误捕获，c.Params("id") 永远为空。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 推荐方案：在所有路由注册前加统一重定向中间件
app.Use(func(c fiber.Ctx) error { path := c.Path() if strings.HasSuffix(path, "/") && path != "/" { uri := c.Request().URI() // 保留 query string qs := string(uri.QueryString()) target := strings.TrimSuffix(path, "/") if qs != "" { target += "?" + qs } return c.Redirect(target, fiber.StatusMovedPermanently) } return c.Next() }) - 前端 SDK、OpenAPI spec、Postman 集合必须全部约定无尾斜杠，否则中间件会持续触发 301
- 别注册
app.Get("/users/", ...)单独处理——维护成本翻倍，且容易遗漏
c.Params() / c.QueryParam() / c.BodyParser() 来源绝对隔离
这三个读取入口互不感知，参数名相同也绝不互通。混用是 90% 的空值问题根源，尤其在前后端联调时极易误判。
-
c.Params("id")只从路径占位符来：仅当路由定义为app.Get("/user/:id", h)且请求是GET /user/123时才有效 -
c.QueryParam("page")只从 query string 来：GET /list?page=2&size=10→c.QueryParam("page") == "2"，跟路径无关 -
c.BodyParser(&v)只认application/json请求体；若前端发的是application/x-www-form-urlencoded，必须改用c.FormValue("name") - 常见翻车：
POST /user?id=123（query 传 ID）却在 handler 里写c.Params("id")→ 永远空字符串
最易被忽略的点：Fiber v3 的 fiber.Ctx 是接口类型，不是指针，所有 handler 签名必须是 func(c fiber.Ctx) error；传参时加 * 或解引用会编译失败。工程化项目里，这点一旦出错，整个路由树直接不加载。
