app.Use("/api")仅匹配路径完全等于/api或以/api/开头（含斜杠），不匹配/apis等；Group前缀需手动对齐，反向代理须在Director中显式截去前缀，参数路由需注意顺序与段数限制。
app.Use()前缀匹配到底怎么算边界
很多人以为app.Use("/api")会像 Nginx 的 location 一样“模糊包含”，其实它只认两种情况：路径**完全等于**/api，或**以/api/开头**（注意斜杠）。这意味着：
-
/api→ 匹配/api和/api/users，但不匹配/apis、/apiv2 -
/api/→ 更安全，明确排除了/api根路径本身，只匹配子路径（如/api/users） -
/→ 等价于全局中间件，所有请求都过，慎用；别写成app.Use("/")想只拦首页
底层靠 hasPartialMatchBoundary 判定，不是字符串 contains，所以别依赖“只要含/api就生效”这种直觉。
Group前缀和子路由路径必须手动对齐
app.Group("/api") 返回的只是一个新 *fiber.Router 实例，它**不会自动拼接前缀**。你写 api.Get("/users", h) 能匹配 GET /api/users，是因为 Fiber 路由树在注册时把 /api 和 /users 拼成了完整路径——但这个拼接是静态的、发生在注册阶段，不是运行时动态补前缀。
- ✅ 正确：
api := app.Group("/api"); api.Get("/users", h)→ 匹配/api/users - ❌ 错误：
api := app.Group("/api"); api.Get("/api/users", h)→ 匹配/api/api/users（多了一层） - ⚠️ 嵌套 Group 如
v1 := api.Group("/v1")+v1.Get("/posts", h)可行，但路径变长、调试时容易看漏前缀层级
建议用常量统一管理前缀，比如 const apiPrefix = "/api"，避免硬编码散落各处。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
反向代理路径重写时前缀处理最容易翻车
用 fasthttp.NewReverseProxy 做代理时，Fiber 的路由前缀（如 /api/*）只是把请求引过来，真正的路径转发逻辑在 Director 里。常见错误是忘了去掉前缀，导致后端收到 /api/users 却只认 /users。
- 必须在
Director中显式调req.URI().SetPath()，不能改req.RequestURI()（只读） - 示例：
if strings.HasPrefix(path, "/api/") { req.URI().SetPath(strings.TrimPrefix(path, "/api")) } - 如果后端要求 Host 头是真实域名，还得加
req.Header.Set("Host", "backend.example.com")
这里没有 Fiber 的事，全是 fasthttp 的行为，别在 Fiber 层试图用 c.Path() 或正则去“修复”路径——太晚了，请求已经发出去了。
参数路由与前缀共存时的匹配优先级
Fiber 的基数树按路径段逐级匹配，:id 和 *path 这类动态节点不会阻断前缀共享，但它们的顺序和位置直接影响是否能命中。
-
/api/:id和/api/users是兄弟节点，互不干扰；但/api/*rest必须放在最后，否则会吞掉所有更具体的路由 -
/api/v1/:id不会匹配/api/v1/users/extra—— 因为:id只吃单一段，要捕获剩余得用/api/v1/:id/*rest - 前缀中间件（
app.Use("/api")）和 Group（app.Group("/api")）都会影响这些路由，但中间件是“全方法+前缀拦截”，Group 是“仅注册该前缀下的路由”，二者作用域不同，别混用
最易忽略的是：路由匹配是精确前缀，不支持通配符回溯。一旦写错一段（比如多一个斜杠），整个路径就掉出树外，404 都不会进中间件——调试时先确认 c.Path() 输出是不是你预期的值。
