fiber默认strictrouting导致/user与/users/被视为不同路由而404；next()是否继续执行取决于是否已写响应；fiber.default()自动挂载logger等中间件而new()为空；queryparam读query string，params读路由参数。
为什么 Fiber 的路由默认不匹配带斜杠结尾的路径
因为 Fiber 默认开启 StrictRouting，它把 /users 和 /users/ 当作两个不同路由。你写 app.Get("/users", ...)，但前端或测试工具发来 GET /users/，就会 404。
常见错误现象：curl http://localhost:3000/users/ 返回 404，而 curl http://localhost:3000/users 正常 —— 你以为是代码写错了，其实是配置没调。
- 关闭方式：初始化时传入
fiber.Config{StrictRouting: false} - 更推荐的做法是显式注册两种路径，或统一用中间件重写（见下一条）
- 注意：关闭后会影响路由匹配顺序，若同时注册
/users和/users/:id，/users/可能被前者捕获，导致/users/123匹配失败
如何让 Next() 在中间件里真正跳过当前 handler
Next() 不是“继续执行下一个中间件”那么简单——它只把控制权交还给 Fiber 的内部调度器，是否继续往下走，取决于当前 handler 是否已写入响应（ctx.Send、ctx.JSON 等）。
常见错误现象：中间件里调了 ctx.Next()，但后续 handler 没执行，日志也没打；或者反复执行多次，像是循环触发。
立即学习“go语言免费学习笔记（深入）”；
- 必须确保中间件里没有提前调用
ctx.Status(200).Send(...)类响应方法，否则 Fiber 认为响应已完成，直接终止链路 - 如果要做权限校验，该返回 401 就返回，别在拒绝逻辑里调
Next() - 调试技巧：在每个中间件开头加
log.Println("in middleware X")，确认执行流卡在哪一环
fiber.New() 和 fiber.Default() 的实际区别在哪
两者都返回 *fiber.App，但 fiber.Default() 是预设了常见中间件的快捷入口：Logger、Recover、RequestID 全都自动挂载。而 fiber.New() 是空应用，什么都没有。
使用场景：本地开发快速验证接口逻辑，用 Default() 省事；生产环境或需要精细控制中间件顺序/参数时，必须用 New() 自行注册。
-
fiber.Default()的Logger中间件会输出完整请求头，可能泄露敏感信息（如Authorization），上线前务必替换或禁用 -
fiber.New(&fiber.Config{...})更适合微服务场景，比如只启用Compress+ 自定义 JWT 验证，避免冗余中间件拖慢延迟 - 性能影响：默认中间件集合会让首字节时间（TTFB）增加约 0.3–0.8ms（实测于 4 核 8G 环境），高并发下不可忽略
为什么 ctx.QueryParam("id") 总是空，但 ctx.Params("id") 能取到
这是 URL 参数类型混淆：前者读的是 query string（?id=123），后者读的是路由参数（/users/:id）。写错地方就永远拿不到值。
常见错误现象：路由定义为 app.Get("/users/:id", handler)，却在 handler 里写 ctx.QueryParam("id")，结果返回空字符串，还怀疑是前端没传。
- 查 URL：如果地址是
/users/123?name=john，那么:id → "123"，QueryParam("name") → "john" - 安全提醒：
ctx.Params()的值未经校验，直接拼 SQL 或传给系统命令极危险；ctx.QueryParam()同理，但至少是用户可控输入，建议统一转成int或用ctx.ParamsInt() - 兼容写法：若想同时支持
/users?id=123和/users/123，得手动合并判断，Fiber 不自动 fallback
app.Listen() 就不能再增删路由或中间件——这点和 Gin 不同，热更新或运行时开关功能得靠外部配置驱动，不是改代码就能生效。 
