Fiber不是微服务框架，而是高性能Web框架；它不提供服务发现、熔断等微服务能力，仅适合作为边缘网关或IoT场景的轻量HTTP底座，实测QPS比Gin高约30%、内存占用为其40%。
Fiber 不是微服务框架，它只是个高性能 Web 框架 —— 但你在特定场景下用它搭微服务，确实能跑得比 Gin 更稳、更省资源。
为什么 Fiber 常被误称为“微服务框架”
搜索“Go 微服务框架”时，很多人把 Fiber 和 go-zero、Kratos 并列，这是概念混淆。Fiber 本身不提供服务发现、熔断、注册中心、配置热加载等能力。所谓“Fiber 微服务”，90% 是开发者自己手写 consul-api 注册逻辑 + 手动集成 prometheus 指标暴露 + 用 fiber.Ctx 封装链路 ID 透传 —— 它没内置这些模块，也不强制你按某种契约组织代码。
真正适合微服务的方案是：go-zero（开箱即用）、Kratos（协议先行）、kitex（专注 RPC 性能）。Fiber 的定位更接近：一个能在边缘节点、IoT 网关、低配容器里扛住高并发 HTTP 请求的轻量底座。
Fiber 在微服务 HTTP 层的真实价值点
如果你的微服务架构已选定 go-zero 或 Kratos，它们的 HTTP transport 层默认用的是 gin；但你可以把它替换成 Fiber，前提是：你愿意承担适配成本，并且业务 HTTP 接口 QPS ≥10k、内存敏感（比如跑在 512MB 的 K3s 边缘节点上）。
立即学习“go语言免费学习笔记（深入）”；
-
Fiber底层基于fasthttp，复用连接池和 buffer，实测在相同 JWT 验证逻辑下，QPS 比Gin高约 30%，内存增长仅为其 40% -
Fiber的fiber.Ctx不兼容net/http生态，像promhttp、httptrace这类标准库中间件不能直接用，必须换fiber.Middleware实现或找社区适配器（如fiber-prometheus） - 本地调试时，
Fiber默认静默失败，要手动加fiber.Config{DisableStartupMessage: false}才能看到启动日志；而Gin的gin.DebugMode会自动打印详细错误页
Fiber 与标准库中间件不兼容的典型报错
常见错误现象：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
把 promhttp.Handler() 直接塞进 Fiber 路由，启动时报 cannot use promhttp.Handler() (type http.Handler) as type fiber.Handler；或者用 http.Request 相关方法（如 c.Request().Header.Get("X-Trace-ID")）时 panic，因为 Fiber 的 ctx.Request() 返回的是 *fasthttp.Request，不是 *http.Request。
正确做法：
- 改用
fiber.Middleware形式封装指标逻辑，例如调用ctx.Locals("start_time", time.Now())记录耗时 - 取 header 用
ctx.Get("X-Trace-ID")，而不是ctx.Request().Header.Get(...) - 需要兼容
net/http工具链时，用fiber.Adaptor包裹，但会损失部分性能（底层仍走fasthttp，只是做了一次转换）
别跳过这个细节：Fiber 启动后看不到日志输出
很多团队上线后发现 kubectl logs -f 一片空白，不是没日志，而是 Fiber 默认关闭启动提示。它不像 Gin 那样自动打印 [GIN-debug] Listening and serving HTTP on :3000。
必须显式配置：
app := fiber.New(fiber.Config{
DisableStartupMessage: false,
})
否则你会在生产环境反复确认 “服务到底启没启”，尤其配合 livenessProbe 时，容易误判为容器未就绪。
真正麻烦的不是性能，而是上下文抽象带来的隐性适配成本 —— fiber.Ctx 看似像 gin.Context，但所有底层行为都绕开了 net/http，连 http.ResponseWriter 都不经过。一旦引入依赖该接口的库（比如某些模板渲染器或旧版监控 SDK），就得重写或绕过。
