fiber不是微服务框架，而是高性能web框架；它不提供服务发现、熔断等微服务能力，仅适合作为边缘网关或iot场景的轻量http底座，实测qps比gin高约30%、内存占用为其40%。
为什么 Fiber.New() 不能直接跑微服务
Fiber 的 fiber.New() 返回的是一个纯 HTTP 路由器，不带服务注册、健康检查端点、依赖注入容器或跨服务链路透传逻辑。所谓“Fiber 微服务”，90% 是开发者手动集成：
- 用
consul-api或etcd/clientv3在app.Listen()前后注册/注销实例 - 自己实现
/health路由并对接数据库连接池状态、下游服务连通性 - 用
ctx.Locals()+ 中间件手动注入 trace ID，并靠ctx.Get("X-Request-ID")向下游透传，而不是依赖 opentelemetry-go 的http.Handler自动注入 - 指标暴露必须用
fiber-prometheus这类适配器，不能直接套promhttp.Handler()
fiber.Ctx 和 net/http.Context 不兼容的典型错误
常见报错：cannot use promhttp.Handler() (type http.Handler) as type fiber.Handler，或调用 c.Request().Header.Get("X-Trace-ID") panic —— 因为 c.Request() 返回的是 *fasthttp.Request，不是 *http.Request。
正确做法：
- 取 header 一律用
c.Get("X-Trace-ID")，不是c.Request().Header.Get() - 读 body 用
c.Body()或c.FormValue()，避免c.Request().Body直接操作 - 需要兼容标准库工具（如某些 zap HTTP 日志中间件）时，用
fiber.Adaptor()包裹，但注意：这会引入额外内存拷贝，QPS 下降约 15–20% - 自定义中间件必须返回
func(*fiber.Ctx) error，不能写成func(http.ResponseWriter, *http.Request)
在微服务架构中用 Fiber 的真实适用场景
别把它当 go-zero 替代品。它只在以下情况值得投入：
- 部署在资源受限环境：K3s 边缘节点（≤512MB 内存）、树莓派集群、车载网关
- HTTP 接口 QPS ≥8k，且多数是简单 JSON 转发（如 JWT 验证后 proxy 到内部 gRPC）
- 已有成熟微服务底盘（如 Kratos），只需替换其
transport/http层以压测性能瓶颈 - 团队熟悉 Express 风格语法，想快速交付 PoC 网关原型，不追求长期可维护性
这时候你真正要写的不是“微服务”，而是“带服务治理能力的 HTTP 胶水层”——Fiber 恰好够轻、够快、够透明。
启动时静默失败？加这个配置才看得到日志
Fiber 默认不打印启动信息，本地调试时 app.Listen(":3000") 卡住或失败，控制台可能完全没输出。必须显式启用：
app := fiber.New(fiber.Config{
DisableStartupMessage: false,
// 还建议加上
ErrorHandler: func(c *fiber.Ctx, err error) {
log.Printf("HTTP error: %v", err)
c.Status(500).SendString("Internal Server Error")
},
})
否则你会花半小时查“为什么端口没起来”，其实只是 JWT 密钥路径错了导致 Listen() panic 后被吞了。
ctx.Locals() 在请求结束时自动清空，但如果你在 goroutine 里异步访问它（比如发 MQ 消息后更新 DB），ctx 可能已被回收。这种 bug 不报 panic，只丢数据。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
