内容摘要：用 Go 写 Web 服务，很多人第一反应是打开 net/http 标准库。这没错，标准库确实能跑起来一个像样的 HTTP 服务，几十行代码就能监听端口、处理路由、返回 JSON。但真到了项目里，路由

用 Go 写 Web 服务，很多人第一反应是打开 net/http 标准库。这没错，标准库确实能跑起来一个像样的 HTTP 服务，几十行代码就能监听端口、处理路由、返回 JSON。但真到了项目里，路由分组、中间件、参数绑定、错误处理这些东西堆上来，裸写标准库就开始难受了。

我最早接触 Go Web 是拿 http.HandleFunc 硬怼，一个文件里塞了三十多个 handler，路由全靠字符串前缀判断。后来同事扔了个 Gin 的示例过来，我才意识到框架解决的问题不是“能不能跑”，而是“跑起来之后代码还能不能看”。

Gin：最顺手的那把刀

Gin 在国内的占有率不用多说。它的 API 设计很直白，r := gin.Default() 然后 r.GET("/ping", func(c *gin.Context) { ...})，基本看一遍就会用。gin.Context 把请求和响应封装在一起，c.JSON(200, gin.H{ "msg": "ok"}) 这种写法省掉了手动设 Header、序列化、写状态码的步骤。

性能上 Gin 用的是自己改过的 httprouter，路由匹配是基数树结构，比标准库的 ServeMux 快不少。不过说实话，大部分业务项目根本压不到那个瓶颈，选 Gin 更多是因为生态——中间件多，社区示例多，遇到问题搜一下基本都有答案。

缺点是 gin.Context 把太多东西耦合在一起了。你要换个非 HTTP 的调用场景，这个 Context 就废了。另外它的绑定和校验依赖 binding tag，写起来有点啰嗦，结构体上挂一堆 form:"xxx" binding:"required"，字段多了看着眼花。

Echo 和 Fiber：两个方向

Echo 的定位跟 Gin 接近，但接口设计更“标准库友好”。它的 echo.Context 是个接口，你可以自己实现，测试的时候 mock 起来方便。中间件写法是 func(next echo.HandlerFunc) echo.HandlerFunc，跟标准库的 http.Handler 链式包装思路一致。如果你团队里有人习惯标准库那套，Echo 的过渡成本最低。

Fiber 走的是另一条路。它底层用的是 fasthttp 而不是 net/http，API 风格模仿 Node.js 的 Express。app.Get("/", func(c *fiber.Ctx) error { return c.SendString("hello") })，写惯了 JS 的人会觉得亲切。性能确实猛，fasthttp 在纯吞吐场景下比标准库高出一截。

但 fasthttp 不是标准库，这意味着 net/http 生态里的东西——比如 httptest、部分中间件、HTTP/2 支持——在 Fiber 里要么没有，要么得换一套写法。我个人的判断是：内部高并发 API 网关可以考虑 Fiber，但需要跟大量标准库生态打交道的项目，别给自己找麻烦。

Chi：小而正

Chi 是我最近用得比较多的。它只做路由，chi.NewRouter() 返回的东西实现了标准的 http.Handler 接口。中间件就是标准的 func(http.Handler) http.Handler，任何兼容标准库的中间件都能直接挂上去。路由分组、URL 参数、通配符这些都有，代码量比 Gin 少得多。

它不帮你做参数绑定，不帮你做 JSON 序列化，这些你自己选库。听起来麻烦，但项目大了之后反而清爽——每一层干什么清清楚楚，不会出现“框架帮你做了但你想改又改不动”的情况。

怎么选

如果团队小、赶进度、需要大量现成中间件，Gin 是默认答案。如果在意跟标准库的兼容性和可测试性，Chi 或 Echo 更合适。Fiber 适合特定场景，别当通用方案用。至于 Beego、Revel 这些老牌全栈框架，现在新项目里已经很少见了，它们试图解决的问题在 Go 社区里逐渐被“组合小库”的方式替代。

框架本身不复杂，复杂的是它背后代表的取舍。选之前想清楚：你是要快，还是要控制力，还是要生态兼容。三个都要，那就得接受某方面打折扣。