HTTP 框架的本质：`net/http`、Gin、Hertz 与 Kitex 的分工

问题

HTTP 服务的本质是什么？为什么要引入框架？net/http、Gin、Hertz、Kitex 各自解决什么问题？

回答

核心结论

先把几件事分清：

• HTTP 服务：对外接收请求并返回响应
• HTTP 框架：帮你更方便地写路由、中间件、参数解析和响应封装
• RPC 框架：主要服务于服务与服务之间的高效调用

如果只记一句话：

Gin 和 Hertz 主要解决“怎么写 HTTP 服务”，Kitex 主要解决“服务之间怎么高效通信”。

HTTP 服务本质上是什么

本质上就是：

1. 你的程序监听一个端口
2. 客户端通过网络发来请求
3. 你的程序解析请求、执行业务逻辑、返回结果

例如天气服务：

• 客户端请求 /weather?city=beijing
• 服务读取参数
• 查询数据
• 返回 JSON

不用框架时会发生什么

Go 标准库 net/http 已经能写服务，但很多通用工作要自己重复写：

• 路由分发
• 方法判断
• 参数提取
• JSON 响应封装
• 中间件编排

这就像“原材料已经有了，但做饭流程全靠自己手搓”。

为什么要用 HTTP 框架

因为业务开发里最容易重复劳动的，就是这几类事情：

问题	如果只用基础设施
路由匹配	手动写很多判断逻辑
参数解析	自己切字符串、读 query/path/body
返回 JSON	每次都手写序列化和响应头
鉴权/日志/恢复	每个 handler 复制一遍

框架的价值，本质上是把这些重复动作抽象成统一机制。

net/http、Gin、Hertz、Kitex 的角色对比

组件	定位	解决的问题	常见场景
net/http	标准库基础设施	提供最底层 HTTP 能力	小服务、学习原理、极简场景
Gin	通用 HTTP 框架	路由、中间件、JSON 响应开发效率	中小型 API、管理后台
Hertz	工程化 HTTP 框架	在 HTTP 层提供更强扩展与性能潜力	高并发服务、CloudWeGo 生态
Kitex	RPC 框架	服务间高效通信	内部微服务调用

Gin 解决了什么

Gin 的价值主要体现在三点：

1. 路由组织更清晰：参数路由、分组路由比手写判断更自然
2. 响应封装更方便：c.JSON(...) 这类 API 减少重复代码
3. 中间件链更统一：鉴权、日志、错误恢复可以统一接入

它的定位很明确：

• 不追求“什么都管”
• 重点提升 HTTP 层开发效率

Hertz 解决了什么

Hertz 也是 HTTP 框架，但更强调：

• 高并发场景下的性能优化空间
• 工程扩展和治理能力
• 与 CloudWeGo 体系的协同

是否选择 Hertz，不是只看“谁 benchmark 更高”，还要看：

• 团队是否熟悉它
• 是否确实有更强的性能与治理诉求
• 是否已在 CloudWeGo 生态中协同开发

Kitex 和 HTTP 框架为什么不是一个东西

HTTP 框架和 RPC 框架面对的是两类不同问题：

类型	面向谁	常见协议	关注点
HTTP 框架	前端、浏览器、外部客户端	HTTP + JSON	易接入、易调试、兼容性
RPC 框架	内部服务	Thrift / Protobuf / gRPC 等	高效、类型约束、服务治理

很多内部 RPC 场景不会优先使用 REST/JSON 风格，是因为：

• 二进制协议通常更紧凑
• 序列化和反序列化成本通常更低
• 服务治理能力更强

但也不要把它理解成“RPC 就一定不用 HTTP”。例如 gRPC 就构建在 HTTP/2 之上，只是它的通信模型和普通 REST API 不同。

一个典型架构分工

客户端 / 前端
    ↓ HTTP
Gin / Hertz（网关或 API 层）
    ↓ RPC
Kitex（内部微服务层）
    ↓
数据库 / 缓存 / MQ

什么时候选哪个

场景	建议
学 Go HTTP 原理	先从 net/http 入手
写常规 REST API	Gin 往往足够
团队偏 CloudWeGo，且对性能/治理要求更高	重点考虑 Hertz
内部服务间高频调用	考虑 Kitex 或其他 RPC 框架

一句话总结

net/http 是基础设施，Gin 和 Hertz 是 HTTP 层开发框架，Kitex 是服务间调用框架；它们不是彼此替代关系，而是分别解决不同层次的问题。

相关问题

• 为什么很多项目会同时用 Gin/Hertz 和 Kitex？ → 因为对外接口和对内调用是两类不同问题，常分别选最合适的方案。
• HTTP 框架越重越好吗？ → 不是，够用最重要，需求和约束能匹配才值得引入。
• 学框架前要不要先学标准库？ → 要，先懂 net/http，再学框架会更容易理解抽象到底解决了什么。

技术拓展

评价一个框架时，别只看性能榜

真正影响选型的通常是这几项：

• 团队熟悉度
• 中间件生态
• 文档质量
• 调试成本
• 服务治理能力
• 与现有技术栈的兼容度

性能很重要，但几乎从来不是唯一标准。