strictrouting默认开启导致路径结尾斜杠差异404；关闭需配置strictrouting:false，但推荐显式注册或重定向；ctx.next()是否执行取决于是否已写响应；上线禁用fiber.default()；避免ctx.body()和strconv.atoi等性能陷阱。
StrictRouting 导致 /users 和 /users/ 404？不是 bug，是默认行为
Fiber 默认开启 StrictRouting: true，它把结尾带斜杠和不带斜杠的路径当作完全不同的路由。你注册了 app.Get("/users", ...)，但 curl http://localhost:3000/users/ 就会 404——这不是你写错了，是配置没对齐。
- 关闭方式：初始化时传
fiber.Config{StrictRouting: false}，例如fiber.New(&fiber.Config{StrictRouting: false}) - 更推荐做法：显式注册两种路径，或用中间件统一重写（比如把
/xxx/301 重定向到/xxx），避免关闭后影响匹配顺序 - 注意陷阱：关掉 StrictRouting 后，若同时有
/users和/users/:id，请求/users/123可能被前者捕获，导致 ID 参数拿不到
ctx.Next() 不执行后续 handler？大概率是你提前写了响应
ctx.Next() 不是“继续跑下一个中间件”，而是把控制权交还给 Fiber 调度器；它是否继续往下走，取决于当前 handler 是否已写入响应（比如调了 ctx.JSON()、ctx.Send() 或 ctx.Status(401).Send()）。
- 常见错误：权限中间件里判断失败后调
ctx.Status(401).Send("unauthorized")，再调ctx.Next()—— 响应已发出，Fiber 直接终止链路，后续 handler 完全不会进 - 正确做法：拒绝就直接 return，别碰
Next()；放行才调ctx.Next() - 调试技巧：每个中间件开头加
log.Println("in auth middleware")，看执行流卡在哪一环；别靠猜
fiber.Default() 和 fiber.New() 别混用，尤其上线前
fiber.Default() 是带预设中间件的快捷入口：自动挂载 Logger、Recover、RequestID；而 fiber.New() 是空应用，什么都没有。
- 开发阶段用
Default()没问题，省事；但上线必须换New()，否则Logger会每秒打几百条日志，I/O 直接拖垮 QPS -
Logger默认输出完整请求头，含Authorization等敏感字段，安全扫描会告警 - 性能影响实测：默认中间件集合让首字节时间（TTFB）增加约 0.3–0.8ms（4 核 8G 环境），高并发下不可忽略
为什么 ctx.Body() 和 strconv.Atoi(ctx.Params("id")) 是性能隐患？
Fiber 底层用的是 fasthttp，它复用内存、避免分配，但你一用标准库惯用写法，就退化成 net/http 水平。
-
ctx.Body()返回的是底层缓冲区拷贝，高吞吐下成为瓶颈；改用ctx.BodyBytes()直接取[]byte引用（前提是不修改内容） -
ctx.Params("id")+strconv.Atoi()多次解析、无缓存、易 panic；改用ctx.ParamsInt("id")，它内置缓存且返回 error -
json.Marshal(data)+ctx.Send(...)绕过 Fiber 优化；直接用ctx.JSON(200, data)，内部用了预分配 buffer 和 unsafe 字符串转换
最常被忽略的点：Fiber 的 ctx 不是标准库 http.Request，所有依赖 context.Context 的下游库（比如 database/sql、redis-go）必须显式调 ctx.Context() 拿原生 context；ctx.Locals 里的值不会自动透传过去。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
