生产环境必须用 fiber.New() 而非 fiber.Default()，因后者自带中间件导致日志泄露、TTFB增加0.3–0.8ms；StrictRouting使/users与/users/视为不同路径而404，应显式注册或重定向；QueryParam读query string，Params读路由占位符，FormValue不适用于JSON。
生产环境直接用 fiber.Default() 启动服务，等于把日志、错误恢复、请求 ID 全塞进响应链——敏感头泄露、TTFB 多 0.3–0.8ms、高并发下 I/O 拖垮 QPS，不是框架慢，是初始化错了。
fiber.New() 和 fiber.Default() 必须分清场景
fiber.Default() 是开发快捷入口，自动挂了 Logger、Recover、RequestID；fiber.New() 是空应用，什么中间件都没有。上线还用 Default，等于每秒打几百条含 Authorization 的完整请求日志。
- 开发阶段用
fiber.Default()没问题，快速验证逻辑 - 上线前必须切到
fiber.New()，再按需加中间件（比如只在 error 时记日志） - 真要日志，别用
fiber.Logger()，改用采样式记录或对接结构化日志系统
StrictRouting 导致 /users 和 /users/ 404 怎么办
Fiber 默认开启 StrictRouting: true，把 /users 和 /users/ 当作两个完全独立的路由。你只注册了 app.Get("/users", ...)，那访问 /users/ 就必然 404——这不是 bug，是匹配规则没对齐。
- 别无脑关掉：
fiber.New(&fiber.Config{StrictRouting: false})，否则/users/123可能被/users匹配，c.Params("id")拿不到值 - 推荐显式注册两条路由：
app.Get("/users", handler)和app.Get("/users/", redirectHandler) - 或加统一重定向中间件：
if strings.HasSuffix(c.Path(), "/") && c.Path() != "/" { c.Redirect(strings.TrimSuffix(c.Path(), "/"), 301) } - 上线前确认前端、SDK、OpenAPI 文档全用无尾斜杠路径
ctx.QueryParam、ctx.Params、ctx.FormValue 到底读哪来的值
三者来源完全不同，混用必空：
在SEO发布前，从路由清单生成XML网站地图和robots.txt
下载
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
立即学习“go语言免费学习笔记（深入）”；
-
c.QueryParam("q")只读 URL query string，比如/search?q=go中的q -
c.Params("id")只读路由占位符，比如app.Get("/user/:id", ...)匹配/user/123后的123 -
c.FormValue("name")是给application/x-www-form-urlencoded准备的；JSON body 必须用c.Body()+json.Unmarshal或c.Struct(&v)
ctx.Next() 不往下执行？大概率你已经写了响应
ctx.Next() 不是“继续跑下一个中间件”，而是把控制权交还给 Fiber 调度器——它是否继续往后走，取决于当前 handler 是否已写入响应（如调了 c.Send()、c.JSON()、c.Status(401).Send()）。
- 权限中间件里判断失败后写了
c.Status(401).Send("unauthorized")，再跟c.Next()，后续所有 handler 都不会进 - 正确姿势：拒绝就
return，别碰Next()；放行才调c.Next() - 调试时每个中间件开头加
log.Printf("→ %s", "auth")，一眼看出卡在哪一层
Radix Tree 路由查找快，但参数节点不校验格式、通配节点只允许末尾出现、大小写默认敏感——这些不是配置项，是底层行为，改不了，只能适配。
