从标准库 net/http 到 Gin、Echo、Fiber、Chi，再到微服务框架 go-zero、Kratos、Hertz——讲清 Go 生态里到底有哪些服务端框架、它们各自定位是什么、底层差在哪、治理能力差在哪，以及你该怎么选。
Go 能在后端占据一席之地，靠的是：编译成机器码（无 JVM/解释器开销）、goroutine 让并发极简、单文件二进制部署、内存占用低且冷启动快（天生云原生）。当你说「Go 的 HTTP 框架」时，通常指两类东西：
只解决「HTTP 请求怎么路由、怎么写 handler、怎么挂中间件」。典型：Gin、Echo、Fiber、Chi。它们本质是更好用的 net/http 封装，不关心服务治理。
在路由之上，额外提供服务发现、负载均衡、熔断限流、链路追踪、配置中心、代码生成、多协议（HTTP+gRPC）。典型：go-zero、Kratos、Hertz/Kitex。它们是「全家桶」。
Go 标准库自带一个完整、够用的 HTTP 实现。绝大多数第三方框架（Gin、Echo、Chi）都基于 net/http 的 http.Handler 接口，只是把路由匹配、中间件、绑定校验等重复劳动包起来。所以「学框架前先懂 net/http」不是情怀，是性价比最高的投资。
// 标准库就能跑起一个 HTTP 服务，无需任何第三方依赖 package main import ( "fmt" "net/http" ) func main() { mux := http.NewServeMux() mux.HandleFunc("/hello", func(w http.ResponseWriter, r *http.Request) { fmt.Fprint(w, "Hello, Go!") }) // ListenAndServe 起服务；:8080 是监听地址 if err := http.ListenAndServe(":8080", mux); err != nil { panic(err) } }
/users/{id} 这种参数化路由、没有正则路由；http.Handler，所以它们能无缝接入所有基于 net/http 的生态——otelhttp、AWS Lambda Go runtime、各类反向代理、Prometheus middleware 都能直接复用。这是 Go 框架「兼容性天花板」高的根本原因。
定位：Go 生态「默认选项」「安全牌」。如果你不知道选啥，选 Gin 大概率没错。
优点：三行起服务、中间件生态最成熟（日志/CORS/限流/鉴权应有尽有）、社区庞大、背靠标准库兼容性无忧。
缺点：不够 opinionated，大项目容易变乱；没有内置依赖注入；context 风格有人不喜欢。
package main import "github.com/gin-gonic/gin" func main() { r := gin.Default() // 默认带 Logger + Recovery 中间件 r.GET("/user/:id", func(c *gin.Context) { id := c.Param("id") // 取路径参数 c.JSON(200, gin.H{"id": id}) // 自动序列化为 JSON }) r.Run(":8080") }
定位：「没有明显短板的老兵」，比 Gin 更结构化，适合团队协作的中大型项目。
优点：代码结构清晰、内置数据绑定与验证器、文档质量高、生产验证多年。
缺点：生态比 Gin 小；高级特性常需额外引库；性能不如 Fiber。
package main import "github.com/labstack/echo/v4" func main() { e := echo.New() e.GET("/user/:id", func(c echo.Context) error { return c.JSON(200, map[string]string{"id": c.Param("id")}) }) e.Start(":8080") }
定位：「Go 里的 Express.js」，为从 Node.js 转来的开发者设计，API 极像 Express。
优点：性能标杆、对 Node 开发者零学习曲线、内置限流/压缩/缓存丰富。
致命代价：用 fasthttp 而非 net/http → 不兼容大量 Go 库、没有 HTTP/2、没有 http.Hijacker 等标准接口、多数可观测性库跑不起来。
package main import "github.com/gofiber/fiber/v2" func main() { app := fiber.New() app.Get("/user/:id", func(c *fiber.Ctx) error { return c.JSON(fiber.Map{"id": c.Params("id")}) }) app.Listen(":8080") }
定位：它自称「路由器」不是「框架」——只做路由分发 + 中间件嵌套，其余（ORM/校验/模板）全靠你自己组合。
优点：极轻量、完全基于 net/http、Clean Architecture 完美搭档、测试容易。
缺点：对新手不友好，基础设施要自己搭；没有 ORM/校验器，小项目起步慢。
package main import ( "net/http" "github.com/go-chi/chi/v5" "github.com/go-chi/chi/v5/middleware" ) func main() { r := chi.NewRouter() r.Use(middleware.Logger, middleware.Recoverer) // 中间件链 r.Get("/user/{id}", func(w http.ResponseWriter, req *http.Request) { id := chi.URLParam(req, "id") // 取参数走标准库风格 w.Write([]byte("user: " + id)) }) http.ListenAndServe(":8080", r) }
提供：MVC 架构、内置 ORM、自动化 API 文档、CLI 脚手架、Session、模板引擎。
适合：中大型单体、想少做架构决策、团队熟悉 Spring Boot/Django。
代价：性能偏低、相对重、社区热度不及 Gin。
提供：类似 Beego 的全功能集合，但 API 设计更现代，性能也更好。
适合：想要「一个框架搞定全部」又不想用 Beego 风格的人。
代价：功能多意味着学习面更大，约定也不如 Gin 轻。
核心卖点：「自带服务治理的微服务全家桶」。内置服务发现、熔断限流、Prometheus 指标、goctl 代码生成（写 .api 生成全套骨架）。
适合：从 0 搭微服务、想要「约定优于配置」、重视稳定性的团队。
代价：有学习曲线和自己的目录约定（本系列已专门讲解）。
核心卖点：强工程化、依赖注入（wire）、清晰的分层、配置/日志/追踪抽象好。
适合：重视架构整洁、愿意用 DI、团队有 Go 工程底蕴。
代价：概念更多，上手比 go-zero 慢一点。
核心卖点：极致性能、Netpoll 网络库、与 Kitex 搭配做内部 RPC。
适合：超高吞吐、已在字节技术栈里、愿意追新。
代价：生态与文档成熟度相比 go-zero 略新。
| 维度 | Gin | Echo | Fiber | Chi | Beego | go-zero | Kratos |
|---|---|---|---|---|---|---|---|
| 类型 | 路由 | 路由 | 路由 | 路由 | 全栈 | 微服务 | 微服务 |
| 底层 | net/http | net/http | fasthttp | net/http | net/http | net/http | net/http |
| HTTP/2 | ✓ | ✓ | ✗ | ✓ | ✓ | ✓ | ✓ |
| 吞吐区间 | 50–70k | 50–65k | 70–110k | 45–60k | 20–40k | 中高 | 中高 |
| 中间件生态 | 最大 | 丰富 | 丰富 | 中等 | 内置 | 内置+可扩展 | 内置+可扩展 |
| 依赖注入 | 无 | 无 | 无 | wire | |||
| 服务治理 | ✗ | ✗ | ✗ | ✗ | 部分 | 内置全套 | 内置全套 |
| 代码生成 | ✗ | ✗ | ✗ | ✗ | CLI 部分 | goctl | proto 生成 |
| 多协议 | 仅 HTTP | 仅 HTTP | 仅 HTTP | 仅 HTTP | 仅 HTTP | HTTP+gRPC | HTTP+gRPC |
| 学习曲线 | 低 | 低~中 | 低 | 中 | 中 | 中~高 | 中~高 |
| 最适合 | 通用 API | 结构均衡 | 极致性能 | Clean Arch | 单体 MVC | 微服务从 0 | 工程化微服务 |
既然你之前让我在 programming-language/golang 下写了 20+ 篇 go-zero 专题，go-zero 这一栏对你不是新概念。下面这些点在本页上方提到的「微服务框架能力」里都有对应落地：
-f + ${ENV}（见 多环境区分）。