c.path()返回匹配后的模板路径（如/users/:id），c.originalurl()返回原始请求路径（如/users/123?format=json）；路由命名需手动通过c.locals注入，不可依赖反射或反向解析。
Fiber 没有内置的“路由名称”概念，c.Path() 和 c.OriginalURL() 是获取路径最直接、最可靠的方式，但二者行为差异明显，用错就拿不到想要的结果。
为什么 c.Path() 返回的是匹配后的路径（不是原始请求路径）
Fiber 的 c.Path() 返回的是经过 radix 树匹配并参数解析后的“规范化路径”，所有路径参数都会被占位符替换。比如你注册了 GET /users/:id，用户请求 /users/123，c.Path() 返回的是 /users/:id，而不是 /users/123。
这是设计使然：Fiber 用它做中间件分流、日志打点、权限校验时，天然需要“模板路径”而非“实例路径”。
- 如果你要记录或比对路由模板（如做 RBAC 白名单），就该用
c.Path() - 它不包含查询参数，也不含 host 或 scheme
- 注意大小写敏感性：若启用
app.StrictRouting = false，c.Path()返回的仍是小写归一化后的路径（如/Users→/users/:id）
c.OriginalURL() 才是原始请求路径（含查询参数）
当你要做重定向、审计日志、或调试真实请求入口时，c.OriginalURL() 更接近直觉——它返回的是客户端发来的完整 path + query，例如 /users/123?format=json。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 它不会被参数解析影响，
:id不会被替换，原始字符串原样返回 - 但它不含 host、scheme、fragment（# 后内容），只保证 path 和 query 部分
- 和
c.Request().URI().String()行为一致，只是封装得更简洁
想实现“路由命名”得自己加 c.Locals
Fiber 不像 Gin 或 Echo 那样支持 Route.Name，但你可以用 c.Locals 在路由注册时手动注入名称：
app.Get("/api/v1/users", func(c *fiber.Ctx) error {
c.Locals("route_name", "get_users_list")
return c.JSON(fiber.Map{"data": []string{}})
})
- 这个值只在当前请求生命周期内有效，不能跨中间件自动继承
- 必须在 handler 开头显式设置，中间件里用
c.Locals("route_name")取，类型是interface{}，需断言 - 别依赖它做关键逻辑（如鉴权），因为容易漏设或拼错键名；更适合日志、监控、OpenAPI 文档生成等辅助场景
别误用 c.Route() 或尝试反射解析
c.Route() 方法不存在 —— Fiber 的 Ctx 接口没暴露路由结构体引用。有人试图从 fiber.App 全局遍历查找匹配路径，这不仅性能差（O(n)），而且在并发请求下无法保证一致性，还绕过了 radix 树的匹配逻辑，极易出错。
- 不要在 handler 里调用
app.Handler()或尝试访问未导出字段（如c.app） - 不要用正则从
c.OriginalURL()反向推路由名，路径参数和通配规则（如/static/*filepath）会让这种做法不可靠 - 真正需要路由元信息（如描述、权限标签），应在注册时通过中间件或封装函数统一注入
Locals，而不是运行时猜测
最易被忽略的一点：Fiber 的路径匹配发生在请求进入时，而 c.Path() 和 c.OriginalURL() 的差异，本质是“路由定义视角”和“客户端请求视角”的分野——选哪个，取决于你下一步要拿这个路径做什么，而不是哪个“听起来更正确”。
