应使用 app.Group("/prefix") 而非 app.Use("/prefix") 设置全局路由前缀，因 Group 会将前缀注入所有子路由注册路径，而 Use 仅控制中间件触发时机，不改变路由匹配路径。
不能用 app.Use("/prefix") 设置全局路由前缀，它挂的是中间件，不是路由前缀。 真正生效的全局前缀必须作用于所有 Get/Post 等路由注册行为，而 app.Use 只是路径匹配 + 中间件执行，不改变后续路由的注册位置。
为什么 app.Use("/api") 不等于“所有路由加 /api 前缀”
它只是让中间件在请求路径以 /api 开头时运行，但 app.Get("/users") 依然匹配 GET /users，不是 /api/users。两者完全独立：一个管中间件触发时机，一个管路由终点绑定位置。
-
app.Use("/api")→ 中间件对/api、/api/foo、/api/v1/bar生效，但不影响app.Get("/users")的匹配路径 - 想让
/users实际响应/api/users，必须把前缀写进路由路径本身，或用Group - 误用
app.Use("/api")还可能干扰静态资源、favicon 等根路径请求，因为它的匹配规则是“前缀+斜杠边界”，/api会匹配/api，但不会匹配/apix或/apis—— 这容易让人误以为它做了路由重写
正确做法：用 app.Group("/api")
Group 返回一个新 *fiber.Router，它本身不自动拼接前缀，但你注册子路由时显式写全路径（含前缀），Fiber 就会按该完整路径注册。这是唯一被框架设计支持的“前缀分组”方式。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 写法：
api := app.Group("/api"); api.Get("/users", handler)→ 最终匹配GET /api/users - 错误写法：
api := app.Group("/api"); api.Get("/api/users", handler)→ 匹配/api/api/users，多了一层 -
Group上注册的中间件（如api.Use(authMW)）只对该组内路由生效，不会泄漏到根路由或其他分组 - 嵌套
Group可行（如v1 := api.Group("/v1")），但每层都需手动管理前缀拼接，建议用常量或变量避免硬编码重复
如果只是想统一加前缀，别碰 app.Use 和手动拼字符串
有人会写 app.Get("/api" + "/users", handler)，这虽然能跑通，但破坏可维护性：前缀散落在各处，改起来容易漏；也不利于 IDE 跳转和文档生成。
- 推荐提取前缀为常量：
const apiPrefix = "/api"，然后api := app.Group(apiPrefix); api.Get("/users", handler) - 不要在
Group外再套app.Use("/api")，否则中间件和路由前缀逻辑分离，调试时难以厘清哪段代码控制哪部分行为 - 注意：Fiber v3 的
RebuildTree()不影响已注册的Group结构，动态增删路由时，Group内的路由仍需按原前缀重新注册
真正要小心的不是“怎么加前缀”，而是“加完之后哪些路由实际被覆盖、哪些中间件意外生效”。Group 隔离了路由注册上下文，Use 只控制中间件作用域——混用这两者却不理解它们的边界，是线上 404 和中间件静默失效的常见源头。
