Fiber默认不处理未知路由，404由底层服务器直返，不经过中间件；需用app.All("*", handler)显式注册兜底路由，且须置于所有路由之后、Listen之前，并配合Static的Fallback: true避免冲突。
Fiber 框架默认不自动处理未知路由，必须显式配置回退逻辑，否则 404 响应由底层 HTTP 服务器（如 net/http）直接返回，无法走中间件链或自定义错误页。
为什么 app.Use() 不能捕获未注册路由
Fiber 的 Use() 是前缀匹配的中间件，只对已注册路由路径前缀生效；未命中任何 Get()/Post() 等路由注册的请求，根本不会进入中间件栈。这是设计使然，不是 bug。
- 比如注册了
/api/users，但访问/api/foo，Use()中间件不会执行 - 所有未匹配路由最终由 Fiber 内置的 404 处理器接管，它绕过全部中间件
- 这意味着 request_id、日志、panic 恢复等中间件对 404 请求完全失效
正确设置 404 回退路由的两种方式
必须在所有具体路由注册之后、app.Listen() 之前，用通配符注册兜底路由：
在SEO发布前，从路由清单生成XML网站地图和robots.txt
下载
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
- 推荐方式：用
app.All("*", handler)捕获所有未匹配方法 + 路径的请求
（注意不是app.Use("*", ...)，Use不支持通配符） - 兼容方式：分别注册
app.Get("*", handler)、app.Post("*", handler)等，覆盖常用方法 - handler 内可调用
c.Status(404)并返回自定义 HTML/JSON，且能正常触发已注册的中间件（如httpx.GinMiddleware()类似逻辑需自行适配）
与 httpx.GinMiddleware() 类中间件的兼容要点
Fiber 无原生 GinMiddleware，但如果你在 Fiber 中封装了类似 panic 恢复 + error 统一输出的中间件，要注意：
- 该中间件必须在
app.All("*", ...)之前注册，否则 404 路由 handler 不会经过它 - 404 handler 内若手动调用
panic或返回error，才能被你的恢复中间件捕获；单纯c.Status(404).SendString("not found")不触发 panic 流程 - request_id 若依赖上下文注入（如
c.Context().Value("request_id")），需确保兜底 handler 仍从c中取值，而非直接读原始http.Request
常见踩坑：静态文件服务与 404 冲突
当使用 app.Static() 提供前端资源时，Fiber 会隐式注册内部路由；若静态路径未命中，它默认返回 404，且不经过你写的 app.All("*", ...)。
- 解决办法：关闭默认 404 行为，改用
app.Static("/", "./public", fiber.Static{Fallback: true}) -
Fallback: true表示静态文件未找到时，继续往下匹配其他路由（包括你的兜底app.All("*", ...)） - 否则，访问
/missing.js会直接返回 Fiber 默认 404 页面，你的自定义逻辑完全不生效
真正麻烦的是兜底路由和静态服务的 fallback 开关耦合——漏掉 Fallback: true 或顺序放错，404 就会静默失效，而控制台没有任何报错提示。
