生产环境建议使用 Fiber v2（如 v2.52.4），因其 API 稳定、文档完善、生态成熟；v3 尚处实验阶段，中间件适配不全、语义化版本未稳定，仅适合早期测试或需流式响应控制的场景。
直接上手 Fiber 项目开发，核心不是“从零搭架子”，而是明确三件事：用哪个版本、怎么组织路由和中间件、以及如何把业务逻辑安全地塞进 fiber.Ctx 生命周期里。Fiber v3 已发布但尚未稳定，生产环境建议锁死 github.com/gofiber/fiber/v2；v2 的 API 兼容性好、文档全、生态成熟，踩坑成本低。
选对版本：v2 还是 v3？
Fiber v3 是实验性分支，引入了 context-aware handler（fiber.Ctx 变成接口）、fiber.Handler 签名变更、SSE 中间件重构等，但目前仍存在：
-
go-fiber/fiber/v3尚未进入 Go Module 的语义化稳定周期，go get拉取可能指向非 tag 提交 - 大量第三方中间件（如
jwt、cors）尚未适配 v3 的新上下文模型 - v3 的
middleware/sse要求显式传入Config.Handler，且内部依赖stream.Event()，而 v2 的sse是函数式封装，更轻量
除非你明确需要 v3 的流式响应控制或准备参与早期测试，否则直接用 v2：
go get github.com/gofiber/fiber/v2@v2.52.4
并在 go.mod 中固定版本，避免自动升级到不兼容快照。
路由与中间件组合：别把逻辑全塞进 Handler
Fiber 的路由写法像 Express，但容易误以为“所有事都能在闭包里干完”。实际中，常见反模式是把数据库查询、鉴权、日志全揉在一个 app.Get("/user", ...) 里。正确做法是分层：
- 前置中间件处理通用逻辑：
app.Use(logger.New())、app.Use(cors.New()) - 路由组（
app.Group("/api")）统一加认证中间件：auth.Middleware()，它应调用c.Locals("user", user)注入用户信息 - 具体路由只做两件事：解析参数（
c.Params("id")、c.Body()）、调用 service 层函数（如userService.GetByID(...)），再用c.JSON()或c.Status().Send()返回
这样既利于单元测试（service 层可脱离 fiber.Ctx 单测），也避免 handler 函数膨胀到百行以上。
响应数据：SendString / JSON / Stream 的取舍
响应方式不是随便选，它直接影响内存、延迟和客户端行为：
-
c.SendString("hello")：纯文本，无 Content-Type 自动设置，需手动c.Set("Content-Type", "text/plain; charset=utf-8") -
c.JSON(v interface{})：自动设application/json，但会触发完整序列化 —— 若返回大结构体（如含二进制字段的模型），考虑先用json.Marshal预序列化并缓存，避免每次请求重复分配 -
c.SendStream(r io.Reader)：适合文件下载或 SSE 流，但注意底层用的是fasthttp，不支持http.Flusher的标准 flush 行为；真要做 SSE，必须用middleware/sse包，它内部已处理flush和心跳注释
例如实现 SSE 推送，不要自己写 c.Set(...); c.Write(...); c.Response().Flush()，而应：
import "github.com/gofiber/fiber/v2/middleware/sse"
<p>app.Get("/events", sse.New(sse.Config{
Retry: 10 <em> time.Second,
Handler: func(c fiber.Ctx, stream </em>sse.Stream) error {
return stream.Event(sse.Event{ Name: "ping", Data: "alive" })
},
}))最后提醒一个易忽略点：Context 生命周期和并发安全
fiber.Ctx 不是线程安全的，不能跨 goroutine 保存或传递。常见错误是：
- 在 handler 内启 goroutine 并试图访问
c（比如异步发邮件后想c.Status(202).SendString()）—— 此时c可能已被回收 - 把
c.Locals()存的 map 当全局缓存用，多个请求共用同一 map 导致数据污染
正确做法是：goroutine 内只处理业务，结果通过 channel 或 callback 回传给主协程；Locals 仅用于单次请求内传递数据，绝不复用其底层结构。Fiber 的高性能正来自这种“一次一清”的上下文模型，破坏它，就等于放弃框架最核心的优势。
