Go Fiber v2是生产环境最稳妥选择，v3仍处beta阶段；需用go get github.com/gofiber/fiber/v2安装v2.x版本；路由参数、查询参数、JSON Body、form-data须严格匹配对应接收方式；ctx返回字符串不可持久化，异步使用需拷贝；中间件顺序影响执行逻辑，日志、JWT校验、静态文件等注册位置需谨慎。
Go Fiber v2 是目前生产环境最稳妥的选择，v3 虽已发布但仍在 beta 阶段，不建议新项目直接上 v3。
初始化项目并安装 fiber/v2
确保 Go 版本 ≥ 1.17（官方最低要求），推荐使用 1.21+。执行以下命令即可完成安装：
go mod init myappgo get github.com/gofiber/fiber/v2
注意：不要用 go get -u，避免意外升级到 v3；go.mod 中应明确看到 github.com/gofiber/fiber/v2 v2.49.0 这类 v2.x 版本号。如果误装了 v3，删掉 go.sum 和 go.mod 中相关行，再重新 go get 即可回退。
路由定义与参数接收必须匹配方式
Fiber 对不同传参方式有严格对应的接收函数，混用会导致取不到值：
- URL 查询参数（如
/user?id=123）→ 用c.Query("id") - 路径参数（如
/user/123）→ 先注册路由app.Get("/user/:id", ...)，再用c.Params("id") - JSON Body（Content-Type: application/json）→ 必须先定义结构体，再调用
c.BodyParser(&u)，不能直接c.Body()后手动解析 - form-data（含文件）→ 普通字段用
c.FormValue("name")，文件用c.MultipartForm()，且需提前调用c.Context().SetBodyLimit(10 * 1024 * 1024)设置上传限制
常见错误：前端发 JSON，后端却用 c.Query() 去读，结果始终为空字符串。
ctx 值默认不可持久化，别存引用
*fiber.Ctx 返回的字符串（如 c.Params("id")、c.Query("q")）底层复用缓冲区，只在 handler 执行期间有效。一旦 handler 返回，这些值可能被下个请求覆盖。
- ❌ 错误写法：
id := c.Params("id"); go doSomething(id)—— goroutine 中 id 可能已变 - ✅ 正确做法：立即拷贝，
idCopy := utils.CopyString(c.Params("id"))，或手动copy()字节切片再转 string - ⚠️ 替代方案：启动时设
fiber.Config{Immutable: true}，但会轻微影响性能，仅在逻辑复杂、难以重构时考虑
这个行为是 Fiber 性能关键所在，也是新手踩坑最多的地方——日志里打印的 ID 是对的，但异步任务里处理的却是别的请求的 ID。
中间件注册顺序直接影响行为
Fiber 中间件按注册顺序依次执行，且 c.Next() 决定是否继续后续中间件和路由 handler。典型陷阱：
- 日志中间件必须放在最前，否则无法统计耗时或捕获 panic
- JWT 校验中间件要放在业务路由之前，但必须在 CORS、Recover 等之后（否则 panic 会绕过校验）
- 静态文件中间件（
app.Static()）建议放在最后，避免拦截 API 请求 - 自定义中间件中若调用
c.SendXXX()或c.Status().SendXXX()，必须 return，否则会继续执行后续中间件，造成重复响应
一个没 return 的鉴权中间件，可能让未登录用户先拿到 401，再被后续 handler 覆盖成 200。
真正难的不是写第一个 app.Get()，而是理解 ctx 生命周期、中间件链式执行模型，以及不同参数来源的语义边界。这些地方一旦出错，问题往往延迟暴露、难以复现。
