Fiber性能最强仅限纯HTTP压测且依赖fasthttp，真实业务中差异可忽略；Gin与Echo性能相近但兼容性更稳；框架开销通常低于5%，选型应优先考虑团队对fasthttp约束的熟悉度。

fiber 在纯 http 层压测中性能最强，但这个“最强”只在特定条件下成立，真实业务里几乎感知不到差异。

---

Fiber 的高 RPS 依赖 fasthttp，不是 magic

• fasthttp 绕过 net/http 的标准对象分配（比如不创建 *http.Request 和 http.ResponseWriter），复用 RequestCtx，减少 GC 压力
• 它禁用 HTTP/2、不支持 http.StripPrefix、不能直接调 http.Redirect 或 http.Error
• 所有依赖标准 http.Handler 接口的中间件（如 prometheus.Handler()、otelhttp.NewHandler）必须显式包装：用 app.Handler() 转成标准 handler，否则 panic
• 错误信息典型是 cannot set header after written，因为 fiber.Ctx 写响应后底层已 flush，再操作 header 就崩

---

Gin 和 Echo 性能差距极小，但兼容性更稳

• 三者在真实链路（带 JSON 序列化 + DB 查询 + 日志）中，框架调度开销通常 <5%，QPS 差距多在 5%～10%
• Gin 的 gin.Context 多一层封装，Echo 的 echo.Context 更轻，但实际影响远不如你写的 SQL 是否走索引、日志是否打在 hot path 上
• Gin 默认启用 Logger 和 Recovery，压测时若没关（gin.SetMode(gin.ReleaseMode)），性能直接掉一半
• Echo 的错误处理集中，HTTPErrorHandler 可统一捕获 panic 和返回码，但中间件注册顺序错位（比如把 auth 放在 Recover 后面）会导致鉴权失效

---

别拿 go test -bench 直接比，那测的不是框架

• 没手动触发 runtime.GC()、没禁用 GODEBUG=gctrace=1、没固定 GOMAXPROCS，结果波动大到没法看
• 压测工具要一致：wrk -t4 -c100 -d30s 比 ab 更贴近真实并发模型
• 必须用 net/http 原生 server 做基线对照，否则你连自己优化的是框架还是底层都分不清

真正卡住吞吐的从来不是路由匹配，而是你没关 debug 日志、JSON 序列化用了反射、或者中间件里同步写了磁盘日志。选框架前，先看团队有没有人熟悉 fasthttp 的生命周期约束——这比跑分数字重要得多。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载