Fiber 的 app.Group() 不自动补前缀，子路由路径必须写全量（含前缀），否则 404；中间件须在 Group() 调用时传入，不可事后 .Use() 补；StrictRouting 开启时 /api 和 /api/ 视为不同分组。
直接说结论：Fiber 的 app.Group() 不是自动补前缀的“魔法盒子”，它只返回一个新 *fiber.Router，子路由路径必须写全量（含前缀），否则 404；中间件必须在 Group() 调用时传入，不能事后用 .Use() 补。
为什么 v1.Get("users", h) 会 404？
Fiber 在注册阶段把 group 前缀和你传入的路径字符串拼起来，但这个拼接不参与运行时匹配——匹配只看最终注册的完整路径。所以：
-
v1 := app.Group("/v1")+v1.Get("users", h)→ 实际注册的是/users，不是/v1/users -
v1.Get("/users", h)→ 注册为/v1/users，能正常匹配GET /v1/users -
v1.Get("/v1/users", h)→ 注册为/v1/v1/users，请求/v1/users必然 404
别依赖 IDE 自动补全或旧框架经验，Fiber 的路径拼接只发生在注册时，且仅由 Group() 的 prefix 和 .Get() 等方法的第一个参数共同决定。
app.Group() 中间件为什么不能用 .Use() 追加？
分组级中间件必须作为参数传给 app.Group()，否则执行逻辑错位：
-
admin := app.Group("/admin", authMiddleware)✅ 正确：该中间件在所有/admin/*匹配成功后、进入 handler 前执行 -
admin.Use(authMiddleware)❌ 错误：这注册了一个USE类型路由，匹配/admin/*所有方法，但它不保证与GET /admin同一执行链，甚至可能因顺序冲突被跳过 - 若同时存在
admin.Get("/", handler)和admin.Use(mw)，mw对GET /admin/可能不生效（取决于路由压缩和注册顺序）
多个中间件按参数顺序执行：app.Group("/api", logger, jwtAuth) → 先 logger，再 jwtAuth，最后 handler。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
嵌套 Group() 容易踩哪些坑？
链式调用如 app.Group("/v1").Group("/users").Get("/list", h) 看似清晰，实际埋雷：
- 路径虽正确（
/v1/users/list），但调试时难以追踪对象来源，v1和users是两个独立*fiber.Group实例 - 中间件作用域割裂：你在
v1上注册的中间件不会自动继承到users子组，除非显式传递 - 重构成本高：想把
/v1/users拆成独立模块时，路径逻辑散落在多层变量中
更稳妥的做法是扁平化声明：v1 := app.Group("/v1")、users := v1.Group("/users")，再 users.Get("/list", h) —— 明确路径归属，也方便后续抽离为函数。
StrictRouting 开启时，/api 和 /api/ 是两个不同分组
Fiber 默认启用 StrictRouting: true，这意味着：
-
app.Group("/api")和app.Group("/api/")创建的是完全隔离的两个分组 -
api := app.Group("/api")+api.Get("/", h)→ 匹配GET /api（无尾部斜杠） - 若用户访问
/api/（带尾部斜杠），默认 404，除非你额外注册api.Get("/", h)或启用caseSensitive: false等配置
这点在 API 文档生成、前端路由跳转、Nginx 代理配置时极易被忽略，建议统一约定是否带尾部斜杠，并在测试用例里覆盖两种请求形式。
