app.Use是前缀级中间件挂载，对所有HTTP方法生效；app.Group是路由分组，创建带公共前缀的独立子树；app.Get/Post仅匹配指定方法和路径；StrictRouting导致/users与/users/被视为不同路由。
app.Get、app.Post、app.Use 和 app.Group 是 Fiber 路由配置的四个核心入口，没搞清它们的职责边界和匹配逻辑，写出来的路由不是 404 就是参数取不到，或者中间件漏执行。
为什么 app.Get("/users") 对 /users/ 返回 404
Fiber 默认开启 StrictRouting: true，这意味着路径末尾斜杠被严格视为不同路由。注册了 /users，就只匹配 GET /users；/users/ 是另一条路径，未注册即 404。
- 别直接关
StrictRouting: false：关掉后/users/123可能被/users错误捕获，因为前缀匹配会松动 - 推荐做法是显式重定向：在所有路由前加一个中间件，对以
/结尾且非根路径的请求做 301 跳转：c.Redirect(strings.TrimSuffix(c.Path(), "/"), 301) - 或统一约定前端、OpenAPI、Postman 全部用无尾斜杠路径，后端只注册一种形式
ctx.Params("id")、ctx.QueryParam("q")、ctx.BodyParser(&v) 到底读哪来的数据
三者来源完全隔离，混用必空值：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
-
ctx.Params("id")只从路径占位符提取，如app.Get("/user/:id", h)匹配/user/123后才可取到"123"；对/user?id=123或 JSON body 无效 -
ctx.QueryParam("q")只解析 URL query string，如/search?q=go&lang=en→"go"；不碰路径、header、body -
ctx.BodyParser(&v)是专为 JSON 设计的，要求 Content-Type 是application/json；若用application/x-www-form-urlencoded，得换ctx.FormValue("name")
app.Use 和 app.Group 的本质区别在哪
app.Use 是前缀级中间件挂载，对所有 HTTP 方法生效；app.Group 是独立路由树节点，用于组织带公共前缀的子路由，但不自动拼接路径。
-
app.Use("/api")表示：所有以/api开头的请求（无论 GET/POST/PUT），都先过这个中间件；它不注册任何 handler，只是拦截 -
api := app.Group("/api")返回一个新*fiber.Router，后续调用api.Get("/users", h)实际注册的是GET /api/users—— 注意：路径参数里必须写全/users，不能省略前缀，Fiber 不会帮你补 - 常见错误：
api.Get("/api/users", h)→ 最终变成/api/api/users，多了一层 - 组内中间件（如
api.Use(auth)）只影响该组下的所有路由，不影响根路由或其他组
通配符 *path 和参数 :id 能不能混着写
不能。Fiber 路由解析是单次线性匹配，通配符只能出现在路径末尾，且不能与参数节点共存于同一段位置。
-
/files/:user/*path→ 启动报错：invalid pattern，因为*path不在末尾 -
/v1//:id→ 不支持，//和:id冲突，引擎无法判定优先级 - 要实现多层动态路径（如
/api/v2/users/123/profile），应拆成/api/:version/users/:id/:section，而不是强行塞通配符 - 末尾可选段用
?：如/posts/:id/:version?，能同时匹配/posts/123和/posts/123/v2
log.Printf("[MIDDLEWARE] %s %s", c.Method(), c.Path())，一眼就能看出请求到底进了哪一层。 
