Go 分类随笔 | NissonCX

Hertz 是什么？适合什么场景？它和 net/http、Gin、Kitex 分别是什么关系？

问题

Hertz 是什么？适合什么场景？它和 net/http、Gin、Kitex 分别是什么关系？

回答

核心结论

Hertz 是 CloudWeGo 提供的 Go HTTP 框架，定位是：

面向 HTTP 服务开发，不是 RPC 框架
强调 工程化能力 + 高并发场景下的性能表现
API 设计上接近 Gin，便于 Go Web 开发者上手

如果只记一句话：

Hertz 解决的是“如何更高效、更工程化地写 HTTP 服务”，Kitex 解决的是“服务之间如何做高性能 RPC 调用”。

它在架构里的位置

组件	定位	常见协议	适用场景
`net/http`	Go 标准库 HTTP 基础设施	HTTP/1.x	小型服务、学习原理、极简场景
Gin	通用 Web/REST 框架	HTTP/1.x	中小型 API、后台系统、社区生态优先
Hertz	高性能 HTTP 框架	HTTP	对性能、扩展性、治理能力要求更高的服务
Kitex	RPC 框架	Thrift / Protobuf 等	微服务之间的内部调用

Hertz 的价值点

维度	说明
开发体验	路由、中间件、分组等接口设计贴近 Gin，上手成本较低
性能潜力	在部分高并发场景下，配合 CloudWeGo 生态可获得更好的吞吐与延迟表现
工程扩展	适合接入统一中间件、治理、代码生成与服务规范
生态协同	与 CloudWeGo 的 Kitex、Netpoll、代码生成工具配合较自然

典型使用方式

package main

import (
    "context"

    "github.com/cloudwego/hertz/pkg/app"
    "github.com/cloudwego/hertz/pkg/app/server"
    "github.com/cloudwego/hertz/pkg/common/utils"
    "github.com/cloudwego/hertz/pkg/protocol/consts"
)

func main() {
    h := server.Default(server.WithHostPorts(":8080"))

    h.GET("/ping", func(c context.Context, ctx *app.RequestContext) {
        ctx.JSON(consts.StatusOK, utils.H{"message": "pong"})
    })

    h.Spin()
}

上面这段代码体现了 Hertz 的常见使用方式：

启动一个 HTTP 服务
注册路由
在 handler 中读取请求、写回响应

路由分组与中间件

func main() {
    h := server.Default()

    v1 := h.Group("/api/v1", authMiddleware)
    v1.GET("/users", listUsers)
    v1.POST("/users", createUser)

    h.Spin()
}

func authMiddleware(c context.Context, ctx *app.RequestContext) {
    if len(ctx.GetHeader("Authorization")) == 0 {
        ctx.AbortWithStatusJSON(consts.StatusUnauthorized, utils.H{"error": "missing token"})
        return
    }
    ctx.Next(c)
}

这个模型和 Gin 很像，本质上是在做三件事：

路由分发：决定哪个请求进入哪个 handler
中间件编排：把鉴权、日志、限流、恢复等通用逻辑前置/后置处理
请求上下文管理：在一次请求生命周期内传递数据

什么时候适合用 Hertz？

场景	是否适合	原因
对外提供 HTTP API 的微服务	适合	框架能力完整，开发体验较好
团队已在使用 CloudWeGo 生态	很适合	与 Kitex 等组件衔接自然
需要统一治理和中间件体系	适合	便于沉淀内部规范
个人练手、小工具脚本	未必需要	`net/http` 或 Gin 往往更轻
内部服务间高性能调用	不合适	这类场景更应优先考虑 Kitex/gRPC

使用 Hertz 的边界

不要把 Hertz 理解成“所有项目都比 Gin 更优”的通用答案。实际选择时更看重：

团队是否已经熟悉它
是否确实需要更强的工程化和性能优化空间
是否要与 CloudWeGo 体系协同

如果项目简单、接口数量少、团队更熟悉标准库或 Gin，那么继续使用原有方案通常更划算。

一句话总结

Hertz 是一个偏工程化、面向高并发 HTTP 服务的 Go 框架；它解决的是 HTTP 层问题，不替代 Kitex 这类 RPC 框架。

技术拓展

一个常见的服务分层方式

客户端 / 前端
    ↓ HTTP
Hertz（网关 / API 层）
    ↓ RPC
Kitex（内部服务层）
    ↓
数据库 / 缓存 / 消息队列

官方资源

GitHub：https://github.com/cloudwego/hertz
文档：https://www.cloudwego.io/docs/hertz/

Go

Hertz 框架基础

问题

回答