生产环境必须用fiber.new()初始化应用，因fiber.default()自带中间件会导致日志泄露、ttfb增加0.3–0.8ms；strictrouting开启时需用重定向中间件处理尾斜杠，而非关闭；参数解析须区分queryparam、params和formvalue；ctx.next()仅在未写响应时生效。
生产环境必须用 fiber.New() 初始化应用，fiber.Default() 仅适合本地快速验证；环境差异不体现在框架本身，而在于中间件组合、路由行为和参数解析方式——错配会导致日志泄露、404 频发、JSON 解析失败。
fiber.New() vs fiber.Default()：上线前必须切换
开发阶段用 fiber.Default() 没问题，它自动挂载 Logger、Recover、RequestID 中间件，省事；但上线后每秒打几百条含 Authorization 头的完整请求日志，I/O 直接拖垮 QPS。实测在 4 核 8G 环境下，TTFB 增加 0.3–0.8ms。
- 上线前必须切到
fiber.New()，它是空应用，什么都没有 - 如需日志，改用采样式（只记 error）或对接结构化日志系统，别用
fiber.Logger() - 若依赖
Recover，手动加fiber.Recover()；RequestID同理，按需显式注册
StrictRouting 导致 /users 和 /users/ 都 404？不是漏写路由
Fiber 默认开启 StrictRouting: true，把 /users 和 /users/ 当作两个完全独立的路径。你只注册了 app.Get("/users", handler)，那访问 /users/ 就必然 404。
- 别无脑关掉：
fiber.New(&fiber.Config{StrictRouting: false})—— 若同时注册了/users和/users/:id，/users/123可能被前者捕获，c.Params("id")拿不到值 - 推荐统一重定向中间件：
if strings.HasSuffix(c.Path(), "/") && c.Path() != "/" { return c.Redirect(strings.TrimSuffix(c.Path(), "/"), 301) } - 上线前核对所有前端调用、SDK、OpenAPI 文档是否都用无尾斜杠路径，否则隐性兼容问题反复出现
ctx.QueryParam、ctx.Params、ctx.FormValue 混用导致取不到值
三者读的是完全不同的位置，混用是常见翻车点：
-
c.QueryParam("q")只读?q=abc这种 query string，不看路径 -
c.Params("id")只读路由定义里的占位符，比如app.Get("/user/:id", )中的:id，对应/user/123里的123 -
c.FormValue("name")是给application/x-www-form-urlencoded准备的；JSON body 必须用c.Body()+json.Unmarshal或c.Struct(&v)
ctx.Next() 不往下走？大概率你已经写了响应
c.Next() 不是“继续执行下一个中间件”，而是把控制权交还给 Fiber 调度器——它是否继续往后跑，取决于当前 handler 是否已写入响应（比如调了 c.Send()、c.JSON() 或 c.Status(401).Send()）。
- 权限中间件里判断失败后写了
c.Status(401).Send("unauthorized")，再跟一句c.Next()：响应已发出，Fiber 直接终止链路，后续 handler 完全不会进 - 正确姿势：拒绝就
return，别碰c.Next()；放行才调c.Next() - 调试时在每个中间件开头加
log.Printf("→ %s", "name")，一眼看出哪一层卡住了
环境配置的本质不是“换 config 文件”，而是明确中间件加载顺序、路由匹配规则、参数解析入口这三件事；任何想靠 StrictRouting: false 或 fiber.Default() 一劳永逸的做法，都会在压测或上线后暴露为难定位的 404、空参数、高延迟。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
