必须用 group 显式分组，否则路由树错乱、子路径失效、参数捕获失败；/:version 通配会劫持一级路径，使 /v1/users/:id 无法注册；group 路径需显式写全但不重复，推荐常量管理前缀；中间件按全局→组级→路由级执行，鉴权应分组绑定而非 handler 内判断；嵌套 group 增加维护成本，建议扁平化如 app.group("/api/v1")；strictrouting 默认开启，末尾斜杠视为不同路径。
必须用 Group 显式分组，不能靠参数或中间件动态分流——否则路由树会错乱、子路径失效、参数捕获失败。
为什么 app.Get("/:version/users", handler) 是危险写法
这种写法看似灵活，实则破坏 Fiber 的基数树结构：
-
/:version是通配参数节点，会提前吞掉所有一级路径（比如/v1、/v2），导致后续注册的/v1/users/:id根本无法命中 - 一旦注册了
/:version/users，再注册/v1/users/:id会被忽略——因为基数树在/v1层已由参数节点接管，不再向下查找静态子节点 -
Accept头协商（如application/vnd.myapi.v1+json）需手动解析，且无法触发路由跳转，纯属业务层逻辑，和路由匹配无关
Group 分组时路径怎么写才不重复
Fiber 的 Group 不自动拼接前缀，子路由路径必须显式带全量路径，但不能“双重拼接”：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- ✅ 正确：
v1 := app.Group("/v1"); v1.Get("/users", h)→ 匹配/v1/users - ❌ 错误：
v1 := app.Group("/v1"); v1.Get("/v1/users", h)→ 实际匹配/v1/v1/users - ❌ 更隐蔽的错误：
app.Group("/v1").Get("/users", h)→ 返回的*fiber.Router没赋值给变量，后续无法注册Post或Use中间件 - 建议把版本号抽成常量：
const v1Prefix = "/v1"，避免字符串散落各处
如何让 v1 和 v2 共享日志但隔离鉴权
中间件执行顺序是固定的：全局 → 组级 → 路由级。利用这点可分层控制：
- 全局中间件（
app.Use(logger, cors)）对所有请求生效，适合日志、CORS、压缩等通用逻辑 - 组级中间件（
v1.Use(authV1)、v2.Use(authV2)）只影响该组内所有路由，包括Get、Post、Head等全部方法 - 不要试图在 handler 里用
c.Params("version")做分支——它不可靠，且绕过了路由树的设计意图 - 如果某条路由需要额外中间件（比如仅
/v2/admin需要 RBAC），可在该路由上链式调用v2.Get("/admin", rbac, handler)
嵌套 Group 容易踩的边界坑
虽然 app.Group("/api").Group("/v1") 语法合法，但会增加维护成本：
- 路径计算变隐式：最终匹配的是
/api/v1/users，但两层Group让前缀来源分散，重构时容易漏改一处 - 中间件叠加复杂：外层
Group的Use会作用于内层所有路由，但内层又可再加Use，调试时难以快速定位执行链 - 推荐扁平化：直接
apiV1 := app.Group("/api/v1")，清晰、可控、易测试 - 注意
StrictRouting默认开启，/api/v1/users/和/api/v1/users是两个不同路径，别指望 Group 自动处理末尾斜杠
最常被忽略的一点：Fiber 的路由匹配发生在请求进入 handler 之前，所有“运行时判断版本”的尝试都晚了一步；真正的版本隔离，必须从 Group 初始化那一刻就固化路径前缀与中间件绑定关系。
