单个路由上应用中间件必须直接传参给app.Get()等方法，而非使用app.Use()；因app.Use()按路径前缀匹配、不区分HTTP方法，无法精准控制作用域，而单路由传参可确保仅该路径该方法执行中间件。
单个路由上应用中间件，必须跳过 app.Use()，直接把中间件函数作为参数传给 app.Get()、app.Post() 等路由注册方法——这是唯一能精准控制作用域的方式。
单路由传参：中间件必须紧挨着路径参数之后
写法很简单，但签名和位置不能错。中间件函数必须放在路径字符串之后、处理器函数之前，且返回类型必须是 func(*fiber.Ctx) error。
-
app.Get("/admin", authMiddleware, handler)✅ 正确：中间件在处理器前，会被执行 -
app.Get("/admin", handler, authMiddleware)❌ 错误：Fiber 不识别 handler 后的额外参数，中间件不会执行 -
authMiddleware若返回nil，请求继续向下；若返回非nilerror，会中断并走错误处理流程 - 多个中间件可连续传入：
app.Post("/upload", ipWhitelist, fileLimit, uploadHandler)
为什么不能用 app.Use("/path", middleware)？
app.Use() 的语义是“前缀挂载”，不是“单路径绑定”。它匹配所有以该字符串开头的路径，且对全部 HTTP 方法生效。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
-
app.Use("/user", m1)会拦截/user、/user/123、/user/profile/edit，甚至/users（如果没加尾部斜杠边界） - 它不区分
GET /user和POST /user/create，只要路径前缀匹配就执行 - 想只让
GET /user走鉴权，而POST /user/login不走？app.Use()做不到，必须用单路由传参
常见报错与坑点
编译或运行时 panic 往往源于签名不符或调用位置错误。
- 编译报错
cannot use authMiddleware (type func(*fiber.Ctx)) as type func(*fiber.Ctx) error→ 中间件函数没返回error，补上return nil - 运行时 panic
panic: interface conversion: interface {} is nil, not *fiber.Ctx→ 可能误把中间件当 handler 直接传给了app.Get("/x", middleware)，漏了最后一个处理器参数 - 中间件执行了但 handler 没触发 → 检查中间件是否忘了
c.Next()或提前return c.SendStatus(401)且没加return - Fiber v3 中
c.Route()在嵌套路由下可能为nil，若你在中间件里依赖它取路径模板（比如对接 Sentinel），需 fallback 到预设标识符
和路由组、全局中间件混用时的顺序陷阱
执行顺序严格按代码书写顺序，不是按注册方式分层。容易忽略的是：单路由中间件实际包裹在路由组中间件“内部”。
-
api := app.Group("/api", jwtAuth)→api.Get("/data", ipWhitelist, handler) - 最终执行链是：
jwtAuth → ipWhitelist → handler，不是反过来 - 如果还写了
app.Use(logger)在最前面，那完整顺序是：logger → jwtAuth → ipWhitelist → handler - 任何中间件里
return都会终止后续，所以日志中间件若放在最后，可能根本打不出记录
真正难的不是写法，而是判断哪些逻辑必须收束到单路由粒度——比如 IP 白名单、敏感操作二次验证、接口级 Sentinel 资源隔离。这些一旦放到 app.Use() 里，要么覆盖太宽，要么漏掉关键路径。
