必须用fiber.new()而非fiber.default()——后者自带logger、recover、requestid中间件，导致敏感头泄露、ttfb增加0.3–0.8ms；strictrouting默认开启使/users与/users/视为不同路径而404，应显式注册或加重定向中间件。
fiber.Default() 开始——它自带日志、恢复、请求 ID 中间件，上线后会泄露 Authorization 头、拖慢 TTFB 0.3–0.8ms，高并发下 I/O 直接压垮。
为什么 fiber.New() 是唯一安全的起点
你不是在“少用功能”，而是在避免默认行为带来的生产事故：
-
fiber.Default()自动挂载Logger：每条请求全量打日志（含 header、body），敏感信息裸奔 - 自动启用
Recover：panic 后返回 500 + 堆栈，前端可直接看到路径、变量名甚至源码行号 - 自动注入
RequestID：看似方便，但若没配采样或对接 tracing 系统，只是多占内存和带宽 - 所有这些中间件共享一个
ctx实例，顺序错一位就可能覆盖响应头或提前写体
正确姿势是：app := fiber.New(&fiber.Config{CaseSensitive: true, StrictRouting: true})，再按需加中间件。开发期用 Default() 没问题，但 CI/CD 流水线里必须检查 fiber.New() 是否已替换。
StrictRouting 导致 /users 和 /users/ 都 404？这不是 bug 是路由契约
Fiber 默认把 /users 和 /users/ 当作两个独立路径。你只注册了前者，后者必然 404——前端发 GET /users/ 就挂了。
- 别关
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) } - 上线前同步检查 OpenAPI spec、前端 SDK、Postman 集合是否全用无尾斜杠路径
ctx.Params("id")、ctx.QueryParam("q")、ctx.BodyParser(&v) 别混着用
三者来源完全隔离，错一个就空值：
-
c.Params("id")只读路径占位符，比如app.Get("/user/:id", ...)匹配/user/123后的"123"；对?id=123或 JSON body 无效 -
c.QueryParam("q")只读 query string，如/search?q=go中的"go"；不解析路径、body、header -
c.FormValue("name")是给application/x-www-form-urlencoded准备的；JSON 必须用c.BodyParser(&v)或json.Unmarshal(c.Body(), &v)，且&v必须传地址
常见翻车：c.BodyParser(v) 忘加 &，解析静默失败，v 保持零值；或在 POST /user 里用 c.Params("id") 想取 ID，结果永远空。
中间件里调了 c.Status(401).SendString() 为啥后续 handler 还执行了
c.Next() 不是“继续往下走”，而是交还控制权给 Fiber 调度器——它是否继续，取决于当前 handler 是否已写响应。
- 权限中间件里写了
c.Status(401).SendString("unauthorized")，就必须return，不能跟c.Next() - 写了响应后还调
c.Next()，Fiber 会忽略后续 handler，但不会报错，调试时极难发现 - 调试技巧：每个中间件开头加
log.Printf("→ auth")，结尾加log.Printf("← auth")，一眼看出哪一层卡住或跳过 - 拒绝请求的中间件，只做两件事：写响应 +
return；放行才调c.Next()
最易被忽略的是：Fiber 的 ctx 是复用对象，c.Params、c.QueryParam 返回的字符串底层指向 fasthttp 的 request buffer，一旦请求结束，内存可能被下一个请求覆盖——别把它存到 goroutine 或全局 map 里。
