17370845950

Go Web框架选型应依实际需求而定：多数新项目用net/http加轻量中间件即可；需路由分组、自动参数绑定等才考虑gin或echo；chi适合需模块化路由又追求轻量与可控的场景。

Go Web 框架选型要看实际需求，不是越流行越好

绝大多数新项目用 net/http + 轻量中间件就足够，除非你明确需要路由分组、自动参数绑定、ORM 集成或 CLI 工具链——否则别一上来就上 gin 或 echo。

什么时候该用 net/http 原生？

适合 API 网关、内部微服务、简单管理后台等对依赖敏感、启动快、内存低的场景。它不是“原始”，而是可控性强：

• http.ServeMux 路由足够清晰，配合 http.StripPrefix 和 http.FileServer 可直接 serve 静态资源
• 中间件写法直白：func(h http.Handler) http.Handler，没有隐式 panic 捕获或上下文透传陷阱
• 调试时能直接看到 http.Request 字段变化，不会被框架封装层遮蔽 body 读取状态
• 编译后二进制体积比 gin 小 2–3MB（实测 12MB vs 15MB），容器部署更轻量

gin 的真实适用边界在哪？

它不是“Go 的 Express”，而是一个为快速原型和中等复杂度 HTTP 服务设计的工具包。真正值得用它的点很具体：

• 需要 c.ShouldBindJSON(&v) 这类自动解绑 + 校验，且模型字段多、校验规则固定
• 团队熟悉 gin.Context 生命周期，能避免在中间件里误调 c.Next() 导致 panic 吞噬
• 要快速启用 gin.LoggerWithConfig 或 gin.Recovery()，而不是自己写日志 middleware
• 不打算长期维护，比如临时数据导出接口、运维脚本 Web 化

注意：它的 gin.Default() 默认开启 Recovery，但会吞掉未处理 panic 的堆栈，线上应改用 gin.New() 自定义中间件。

立即学习“go语言免费学习笔记（深入）”；

别忽略 chi 这个“安静的选择”

如果你需要模块化路由、子路由器嵌套、URL 参数强类型提取，又不想接受 gin 的运行时反射开销或 echo 的泛型侵入，chi 是目前最平衡的方案：

• 基于 net/http 构建，无额外依赖，chi.Router 实现了 http.Handler
• 支持 r.Route("/api", func(r chi.Router) { ... })，天然适配微服务网关拆分
• 中间件是纯函数：func(http.Handler) http.Handler，和原生完全兼容
• 没有自动 JSON 绑定，但搭配 json.Unmarshal + errors.As 更易测试和 debug

func main() {
	r := chi.NewRouter()
	r.Use(loggingMiddleware)
	r.Get("/health", healthHandler)
	r.Route("/api/v1", func(r chi.Router) {
		r.With(authMiddleware).Get("/users", usersHandler)
	})
	http.ListenAndServe(":8080", r)
}

框架本身不解决业务复杂度，只影响你暴露 bug 的方式。一个没写好 io.Copy 的 handler，在 net/http 里会直接 500，在 gin 里可能变成空响应加静默 panic，在 chi 里则取决于你中间件是否 recover —— 关键永远是你怎么写 handler，不是用什么框架。