数据核对：2026-10-22（GitHub API 实测） 本文只讨论「选哪个框架」，具体用法见各框架入门文章。
先说结论
- 不确定选谁 → Gin。生态最大，遇到问题搜得到答案
- 喜欢标准库风格、不想被框架绑定 → Chi，或者干脆用
net/http - 要极致性能、接受非标准实现 → Fiber
- 做微服务、要服务治理 → go-zero 或 Kratos
- 只要 HTTP 路由，不要全家桶 → Echo
Go 的框架生态和前几年不一样了：标准库越来越强，框架的地位在下降。net/http 在 Go 1.22 之后支持了路径参数和方法匹配，很多原来必须上框架的场景现在不用了。
一、先分清三类东西
| 类别 | 是什么 | 代表 |
|---|---|---|
| HTTP 路由框架 | 路由 + 中间件，加上一点辅助工具 | Gin、Echo、Fiber、Chi |
| 微服务框架 | 服务发现、配置中心、链路追踪、代码生成 | go-zero、Kratos、Kitex |
| 标准库 | net/http + ServeMux | 官方 |
最常见的误判是把微服务框架当 Web 框架用。go-zero 和 Kratos 生成的脚手架包含注册中心、配置中心，部署时要配套基础设施。一个人写个小 API 用 go-zero，等于给自己上枷锁。
二、五个框架的真实状态
| 框架 | star | 最新版本 | 定位 |
|---|---|---|---|
| Gin | 89,413 | 1.12.0 | 事实标准，中间件生态最广 |
| Fiber | 40,231 | 3.6.1 | Express 风格，基于 fasthttp |
| go-zero | 33,398 | — | 微服务全家桶，国内流行 |
| Echo | 32,777 | — | API 友好，文档清晰 |
| Kratos | 25,984 | — | B 站开源，微服务 |
| Chi | 22,983 | — | 贴合标准库，代码量极小 |
三、逐个说清
Gin
Go 世界里的事实标准。路由、参数绑定、中间件、分组、JSON 渲染都有，API 设计接近 Express，上手快。
代价： – 用 interface{} 和反射做参数绑定，性能不是最优 – gin.Context 是框架自家类型，写出来的 handler 和标准库不兼容，换框架要全改 – 官方维护节奏不算快（1.12.0 是 2026-02），bug 修得慢
适合：绝大多数后端 API。选它不是因为最好，是因为遇到问题最容易找到答案——这一点在团队协作里比技术指标重要。
Echo
和 Gin 定位最接近，差异在细节：
- 参数绑定和校验比 Gin 更规范（内置 validator 集成）
- 中间件接口设计更统一
- 文档质量比 Gin 好
代价：社区规模大约是 Gin 的三分之一，中文资料少。
适合：喜欢更严谨的 API 设计、对参数校验有要求的项目。
Fiber
基于 fasthttp 而不是 net/http，所以快。API 风格照搬 Express，从 Node.js 转过来几乎零学习成本。
代价很关键：
- 不兼容
net/http。大量 Go 生态的库（中间件、监控、pprof）是为net/http写的，Fiber 用不了或要适配层。 fasthttp复用请求对象，不能把*fiber.Ctx存起来跨请求使用。这是个真坑，很多人踩过。- 不支持 HTTP/2 的服务端推送等标准特性。
适合：追求吞吐量、做内部高性能服务、团队从 Node.js 迁过来。
不适合：需要大量现成中间件、需要和标准库生态混用。
Chi
只有一个路由器，别的什么都不做。它实现的是 http.Handler 接口，所以能和任何标准库生态的中间件组合。
代码量极小（几千行），读得完，不用担心里面藏了什么魔法。
适合：想要完全控制权、不愿意被框架绑定、项目会活很久的场景。
go-zero
国内流行的微服务框架。核心是代码生成：写 .api 描述文件，生成 handler、logic、model 三层骨架。配套 goctl 工具、内置限流熔断、链路追踪。
代价： – 强约定。目录结构、分层方式都由框架定，改起来别扭 – 依赖较多基础设施（配置中心、注册中心，虽然可以单机简化） – 文档偏工具手册，原理讲得少
适合：团队做微服务、接受约定优先、需要快速产出大量服务。
Kratos
B 站开源的微服务框架，理念和 go-zero 类似但更「正统」：基于 gRPC，proto 优先，分层清晰（api / biz / data / service）。
代价：学习曲线比 go-zero 陡，gRPC 是默认而不是可选项，不适合纯 HTTP 项目。
适合：以 gRPC 为主的服务间通信、需要标准化分层的团队。
四、按场景选
| 场景 | 推荐 | 理由 |
|---|---|---|
| 小项目 / 单人开发 | Chi 或 net/http | 依赖少，出问题好查 |
| 一般业务 API | Gin | 生态最大 |
| 需要严谨校验 | Echo | 绑定和校验做得更好 |
| 极致吞吐 | Fiber | fasthttp 的性能优势真实 |
| 微服务、要治理 | go-zero 或 Kratos | 配套齐全 |
五、一个被忽略的选项：标准库
Go 1.22 之后，net/http 的 ServeMux 支持：
mux := http.NewServeMux()
mux.HandleFunc("GET /users/{id}", getUser) // 方法 + 路径参数
mux.HandleFunc("POST /users", createUser)
如果你的需求只是「路由 + JSON」，标准库已经够了。 框架带来的价值主要在中间件生态和参数绑定，不是路由本身。
判断标准：你需要几个第三方中间件？ 少于三个，用标准库自己写，比引入框架更省事。
六、延伸阅读
- Gin 框架入门
- Echo 框架入门
- Fiber 框架入门
- go-zero 微服务入门
- Kratos 微服务入门