app.Group()是Fiber中唯一安全的嵌套路由方式，因为它将前缀注入每条子路由完整路径，确保参数提取、中间件匹配、静态服务及OpenAPI生成全部对齐；手动拼接易致404、参数丢失、维护困难。
嵌套路由在 Fiber 里不是原生语法支持的“子路由对象”，而是靠路径前缀 + app.Group() 显式构造出来的逻辑分组；直接拼接字符串或依赖中间件自动补前缀，大概率导致 404 或参数丢失。
为什么 app.Group() 是唯一安全的嵌套路由方式
Fiber 的 app.Group() 不是语法糖，它会把前缀注入到每条子路由的完整路径中，并确保 c.Params()、中间件匹配、静态文件服务等行为全部对齐。不使用它而手动拼接，比如写 app.Get("/api/v1/users", h) 再写 app.Get("/api/v1/posts", h)，虽然能跑，但无法复用中间件、版本升级时难维护、Swagger 文档生成也容易错位。
-
app.Group()返回的新路由实例自带独立中间件栈，group.Use()只影响该组内所有路由 - 路径前缀末尾是否带
/会影响匹配：app.Group("/api")和app.Group("/api/")在 StrictRouting=true 下是两个不同前缀 - 嵌套调用
group.Group()是合法的，比如v1 := api.Group("/v1"); users := v1.Group("/users")，最终注册的是/api/v1/users/:id
app.Group() 和 app.Use() 混用时的常见陷阱
app.Use() 是中间件挂载点，不是路由分组工具。它只控制中间件执行时机，不改变路由注册路径。如果误用 app.Use("/api", middleware) 代替 app.Group("/api")，会出现以下问题：
- 中间件确实会生效，但
app.Get("/users")注册的仍是根路径/users，不是/api/users - 前端请求
/api/users会 404，因为没注册这条路由 - 想让
/api/users匹配成功，必须显式写app.Get("/api/users", h)，否则中间件白挂 -
app.Use()对POST、PUT等方法也生效，但你可能只想给GET加日志，这时该用group.Get().Use()
嵌套路由下参数提取和重定向的边界情况
路径结构越深，c.Path() 和 c.OriginalURL() 的差异越关键。比如注册了 api.Group("/v1").Get("/users/:id", h)，当请求 GET /v1/users/123?format=json 时：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
c.Path()返回/v1/users/123（不含 query） -
c.Params("id")正确拿到"123" -
c.QueryParam("format")正确拿到"json" - 但如果在中间件里做重定向，比如把
/v1/users/→/v1/users，注意用c.Redirect(strings.TrimSuffix(c.Path(), "/"), 301)，别用c.OriginalURL()，后者含 query，会导致跳转后 query 重复或丢失
上线前必须检查的三处嵌套细节
嵌套路由配置容易在本地跑通，上线后因反向代理、CDN 或前端 SDK 路径拼接出错而失败。重点核对：
- 所有
app.Group()前缀是否与 Nginx 的location配置一致，比如 Nginx 写了location /api/ { proxy_pass http://backend/; }，那 Fiber 就得用app.Group("/api")，不能多一个/，否则实际匹配路径变成/api//v1/users - OpenAPI spec 中的
basePath或server.url是否和 Group 前缀对齐，否则 Swagger UI 发起的请求会 404 - 前端 Axios 或 Fetch 的
baseURL是否漏掉 Group 前缀，比如后端是app.Group("/v2")，前端却设成baseURL: "/api"，结果所有请求发到/api/users而不是/v2/users
嵌套路由真正的复杂点不在怎么写，而在路径语义是否贯穿整个链路——从反向代理、Fiber Group、OpenAPI 描述，到前端请求构造，任意一环斜杠多一个、少一个、位置不对，都会让参数消失或 404 报错。别依赖调试时“看起来能通”，上线前逐层比对原始请求路径才是最省时间的做法。
