Fiber 官方 @fiber/ 系列中间件中不存在 rewrite 内置中间件，不支持服务端路径重写；仅提供重定向（c.Redirect）和路由匹配能力，真 rewrite 需由反向代理层（如 Nginx）或提前注册兼容路由实现。
Fiber 没有内置 Rewrite 中间件
Fiber 官方 @fiber/ 系列中间件中**不存在名为 rewrite 的内置中间件**。你不会在文档里找到 fiber.Rewrite() 或 rewrite.New() 这样的 API。常见误解是把 Nginx 的 rewrite 规则、Spring Cloud Gateway 的 RewritePath 或 Express 的 res.redirect() 逻辑直接套用到 Fiber 上——它不提供路径重写（URL rewriting）语义，只提供重定向（redirection）和路由匹配能力。
想实现类似 rewrite 的效果，得靠路由参数 + c.Next() 手动接管
所谓“重写请求路径”，比如把 /old/:id 内部转成 /api/v2/users/:id 并继续走后续路由，Fiber 不会自动改 c.Path() 或重放请求。你必须自己解析、替换、再调用 c.Next() 让请求继续向下匹配：
- 用
c.Params()或c.Query()提取原始路径中的关键字段 - 手动拼出新路径，例如
newPath := "/api/v2/users/" + c.Params("id") - 修改
c.Request().URI().SetPath(newPath)（⚠️注意：这仅影响当前请求对象的 URI 缓存，不触发重新路由匹配） - 更可靠的做法是：提前注册目标路由（如
app.Get("/api/v2/users/:id", handler)），然后在旧路由里用c.Redirect()或直接复用 handler 逻辑
硬要“伪 rewrite”，典型错误是只改 Request.URI().SetPath() 却没注册对应路由，结果 404；或误以为改了 path 就能自动进新路由组——Fiber 路由匹配发生在中间件执行前，中途改 path 不会回溯重匹配。
替代方案：用 app.All() + c.Route() 做前置路径映射
如果目标是统一将一批旧路径映射到新结构（如所有 /v1/* → /api/v2/*），推荐用通配路由 + 显式转发逻辑：
app.All("/v1/*", func(c *fiber.Ctx) error {
oldPath := c.Path()
newPath := strings.Replace(oldPath, "/v1/", "/api/v2/", 1)
// 注意：不能直接 c.Path(newPath)，Fiber 不允许写入
// 正确做法：提取参数后调用目标 handler，或返回 301
return c.Redirect(newPath, 301)
})
或者更彻底地，在启动时批量注册映射规则：
- 维护一个
map[string]string存路径映射表 - 在中间件里查表，命中则
c.Redirect(target, 301) - 避免在 handler 里做字符串替换后再
c.Next()—— Fiber 不支持运行时动态插入路由
别混淆 Redirect 和 Rewrite：301/302 是客户端跳转，不是服务端路径重写
这是最容易被忽略的底层差异：c.Redirect() 发的是 HTTP 301/302 响应，浏览器收到后发起**全新请求**；而 Nginx 的 rewrite ... last 是服务端内部重写 URI 后继续走 location 块，客户端无感知。Fiber 作为 Go HTTP 框架，天然不具备后者能力。如果你需要真正的服务端路径重写（比如兼容遗留前端 URL 结构但后端已重构），必须：
- 要么在反向代理层（Nginx / Cloudflare / ALB）完成 rewrite
- 要么在 Fiber 路由定义时就覆盖所有旧路径，用相同 handler 处理
- 要么接受 301 跳转，并确保前端能正确处理 Location 头（尤其 SPA 应用需配置 history fallback）
试图用中间件“模拟 rewrite”往往导致路由错乱、日志路径与实际处理路径不一致、监控指标失真——因为 c.Path() 始终是原始请求路径，改不了。
