app.Group() 是配置路由前缀的正确方式，它返回独立的 *fiber.Router 实例，需在子路由中显式写出完整路径（含前缀），Fiber 不自动拼接；Use 仅注册中间件，不定义路由；StrictRouting 默认开启，严格区分尾部斜杠。
app.Group() 是配置路由前缀的正确方式
Fiber 不支持自动拼接前缀，app.Group() 返回的是一个独立的 *fiber.Router 实例，它本身不修改路径，但为你提供一个作用域来注册带统一前缀的路由。关键在于：你必须在子路由中显式写出完整路径（含前缀），否则前缀不会生效。
常见错误是以为 app.Group("/api") 后写 api.Get("/users", h) 就会匹配 /api/users——这确实能工作，但不是因为“自动拼接”，而是因为 Get 的第一个参数就是完整路径；如果你写成 api.Get("users", h)（漏掉开头斜杠），就完全不匹配。
-
api := app.Group("/api")→ 后续所有api.Get("/xxx", ...)中的/xxx会被当作相对于根路径的全量路径，Fiber 内部不做字符串拼接 - 想复用前缀又避免硬编码？用变量：
prefix := "/api/v1"，然后api := app.Group(prefix)，再api.Get(prefix + "/users", h)或更清晰地直接app.Get(prefix + "/users", h) - 嵌套
Group可行但易混乱：v1 := app.Group("/api/v1"); users := v1.Group("/users")，此时users.Get("/list", h)匹配的是/api/v1/users/list，但可读性下降，调试时容易搞错层级
别把 Use 当作路由前缀配置工具
app.Use("/api", handler) 看似像前缀配置，但它注册的是中间件，不是路由终结点。它会对所有以 /api 开头的请求（无论 GET/POST/PUT）执行 handler，但不会自动转发到子路由——如果你没另外定义 app.Get("/api/users")，那请求 /api/users 仍会 404。
典型误用场景：
- 只写
app.Use("/api", middleware)，没注册任何Get/Post→ 请求进来后 middleware 执行了，但没后续处理，最终返回 404 - 把
app.Use("/api", subApp)当作子应用挂载 → 这其实是合法用法（subApp 是另一个 Fiber app），但 subApp 内部的路由仍需自己定义，且它的/users会响应/api/users，前提是 subApp 没设自己的 Group 前缀 - 混用
Use和Group：比如app.Use("/api", middleware)+app.Group("/api").Get("/users", h)→ 中间件会执行两次（一次 via Use，一次 via Group 继承），逻辑失控
StrictRouting 对前缀匹配的影响不能忽略
Fiber 默认开启 StrictRouting: true，这意味着路径末尾的斜杠会被严格区分。比如你用 app.Group("/api").Get("/users", h)，它只匹配 /api/users，不匹配 /api/users/（带尾部斜杠）。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
这不是 bug，是设计选择。强行关闭 StrictRouting 可能引发歧义，例如：
-
app.Get("/users", h1)和app.Get("/users/:id", h2)在 strict 模式下互不干扰 - 一旦关掉 strict，
/users/123可能被误判为/users后跟多余路径，导致h1被触发而h2失效 - 所以更稳妥的做法是：统一约定接口不带尾部斜杠，或对关键路径显式补全，如
app.Get("/users/", hRedirect)做 301 跳转
动态增删前缀路由风险极高，仅限开发环境
有人试图用 app.RemoveRoute() + app.RebuildTree() 在运行时修改前缀，比如把 /v1/users 切换为 /v2/users。这在技术上可行，但文档明确标注为 “very performance-intensive”，且非线程安全。
真实项目里踩过的坑：
- 并发请求中调用
RebuildTree()可能导致路由树状态不一致，部分请求 404 或命中错误 handler - 删除旧路由后未及时
RebuildTree()，新请求仍走旧逻辑；重建后旧连接可能还在用老树节点，出现短暂不一致 - Group 继承的中间件不会随
RemoveRoute()自动解绑，需手动管理生命周期
真正需要灰度切换前缀时，应该用反向代理或负载均衡层做路径重写，而不是在框架内动态改路由树——后者是调试手段，不是架构方案。
