Fiber 路由由注册顺序、前缀语义和参数解析共同决定;StrictRouting 默认开启,需显式处理 /users 与 /users/;参数路由性能优于通配路由;app.Use 作用于所有 HTTP 方法,app.Get 仅限 GET;子应用挂载必须用 app.Use。

Fiber 的路由不是“配出来”的,而是靠注册顺序、前缀语义和参数解析方式共同决定的——写错一个斜杠、漏掉一个 StrictRouting 配置,就可能让 /users 和 /users/ 互不识别,或让 /user/:id 匹配到不该匹配的路径。
StrictRouting 开关怎么选?别关,要显式处理
Fiber 默认开启 StrictRouting: true,这意味着 /users 和 /users/ 是两条完全独立的路由。你只注册了前者,后者访问必 404。
- 错误做法:全局关掉
StrictRouting: false—— 后果是/users/:id可能被/users意外捕获,c.Params("id")拿不到值 - 推荐做法:显式注册两种路径:
app.Get("/users", handler)+app.Get("/users/", handler) - 更优做法:加个中间件统一重定向:
app.Use(func(c *fiber.Ctx) error { if strings.HasSuffix(c.Path(), "/") && c.Path() != "/" { return c.Redirect(strings.TrimSuffix(c.Path(), "/"), 301) } return c.Next() })
参数路由 vs 通配路由:性能差 3–5 倍,别乱用 *
app.Get("/user/*", handler) 看起来方便,但底层走的是线性匹配,每条请求都要遍历所有通配节点;而 app.Get("/user/:id", handler) 走 Radix 树,O(log n) 查找。
- 通配路由
*只能出现在路径末尾,不能写成/user/*/profile - 参数路由不校验格式:
/user/abc也能匹配/user/:id,真要校验请用 v3 的RegisterCustomConstraint - 需要多段动态路径?用嵌套参数:
/post/:year/:month/:slug,别退化成/post/*
app.Use 和 app.Get 的本质区别:方法覆盖范围不同
app.Use 注册的是中间件,对所有 HTTP 方法生效(GET/POST/PUT/DELETE…),而 app.Get 只响应 GET。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景,三层路由架构(触发词→SAD反馈→DAG编排),recall@10=96.97%。配置驱动(chains.yaml),零代码扩展。pip install skill-weave-chains 一键安装。
-
app.Use("/api", middleware)→ 所有以/api开头的请求(无论方法)都进这个中间件 -
app.Use("/api")不等于app.Use("/api/"):前者匹配/api和/api/foo,后者只匹配/api/和/api//bar(注意双斜杠) - 子应用挂载必须用
app.Use("/admin", adminApp),不能用app.Get("/admin", ...),否则 POST 请求进不来
路径前缀挂载最容易漏掉的三个细节
静态资源、反向代理、子应用都依赖前缀挂载,但 Fiber 对前缀的匹配非常严格,稍不对齐就 404。
-
app.Use("/assets", static.New("./public"))→ 访问/assets/logo.png才有效;写成app.Use("/assets/", static.New(...))会导致/assets/logo.png匹配失败 - 反向代理必须用
fiber.WrapHandler包装fasthttp.ReverseProxy.ServeHTTP,不能直接传函数,否则ctx.Send()失效 - 子应用路由里写的
app.Get("/dashboard"),挂载后实际访问路径是/admin/dashboard(如果挂载点是/admin),子应用内部不感知前缀
Fiber 路由的“配置感”很弱,它几乎不做自动推导——你写什么,它就认什么。最常出问题的地方不在语法,而在对前缀边界的理解、对 StrictRouting 行为的误判,以及把 Use 当成 Get 用。上线前务必用 curl 实测 /path、/path/、/path?q=1 三种情况是否都符合预期。










