fiber核心在于避坑而非用法：生产环境优先选稳定v2.x，v3仅限实验性场景；需注意net/http生态不兼容、v3中间件签名变更、路由隐含head注册、sse需自行管理连接与广播、中间件顺序关键。
Fiber 不是“怎么用”的问题，而是“从哪切入、避开哪些坑”的问题。v3 已发布但尚未稳定，生产环境仍应优先选 v2.x；若已决定用 v3，请注意它不兼容 net/http 生态（比如 gqlgen、go-swagger 无法直接接入）。
安装与版本选择必须明确
别直接 go get github.com/gofiber/fiber/v3 —— 这会拉取未冻结的开发分支，行为可能突变。
生产项目请锁定 v2 最新版：
go get github.com/gofiber/fiber/v2@latest
v3 仅建议用于实验性长连接场景（如 SSE），且需同步确认 Go 版本为 1.22+（v3 已验证兼容 1.22/1.23）。
-
v2：API 稳定、文档全、中间件生态成熟（如jwt、cors、rate-limit） -
v3：引入fiber.Ctx泛型重写、sse中间件内建、默认启用更激进的内存复用，但Handler签名变更，v2 中间件不能直接复用
路由注册别漏掉方法绑定语义
Fiber 的 Get/Post 等方法不是语法糖，而是对 Add 的封装，且隐含了 Head 预注册（app.Get("/x", h) 实际同时注册了 GET 和 HEAD）。这意味着：
- 若你手动用
Add("GET", "/x", h)，HEAD /x将 404 - 动态参数必须用
:id形式（/user/:id），不支持正则路径（如/user/\d+）——那是chi或gorilla/mux的玩法 -
app.All("/path", h)会匹配所有方法，但不会自动处理OPTIONS预检；跨域需额外配cors中间件
SSE 推送必须自己编排流逻辑
sse.New 只负责传输层：设置 Content-Type: text/event-stream、逐帧 flush、注入心跳注释、检测客户端断连（靠 stream.Write 返回 io.ErrClosedPipe）。它不管理消息分发、不维护连接列表、不处理重连状态。
-
Config.Retry是写在流开头的retry: 5000，只影响浏览器EventSource的重连间隔，不影响服务端是否重试推送 -
stream.Event()写的是单条事件帧；若需广播，得自己实现类似hub的结构，用map[*sse.Stream]bool存活连接，并在业务中遍历写入 - 不要在
Handler里做阻塞操作（如 DB 查询）——它运行在请求 goroutine 中，阻塞会导致流卡死；应改用带超时的异步通知（如 channel + select）
中间件链顺序直接影响行为
Fiber 中间件是线性执行的，顺序错一位就可能让认证失效或日志漏打。典型陷阱：
-
logger放最前：能记录所有进入的请求，包括 404 -
recover必须放第二（紧接 logger）：否则 panic 会绕过它直接崩溃 -
jwt类认证中间件，必须放在业务路由之前，且注意它默认只校验Authorization: Bearer xxx，不处理 cookie 或 query 参数 - 自定义中间件若调用
c.Next()后还写响应（如c.SendString），会导致http: superfluous response.WriteHeader错误
最易被忽略的是：v3 的中间件签名从 func(*fiber.Ctx) error 变为 func(fiber.Ctx) error（值接收），旧 v2 中间件不能混用。
