Hertz 本质是嵌入式 HTTP 框架，其超高性能依赖显式启用 Netpoll 传输器、规避 net/http 调度陷阱及合理配置启动参数；server.New() 默认回退标准库，须手动指定 netpoll.NewTransporter 才能维持 4000 万 QPS 级表现。
直接说结论：Hertz 本身不「部署」，而是被集成进 Go 服务进程里运行；所谓“超高性能 HTTP 请求分发”，本质是用对 Netpoll、配对的 server.New 选项、以及避开标准库 net/http 的调度陷阱。不是换框架就能自动变快，关键在启动方式和网络层选型。
启动时必须显式指定 Netpoll 传输器
Hertz 默认确实用 Netpoll，但这个“默认”只在 server.Default() 里生效；一旦你调用 server.New() 自定义配置（比如加 TLS、改监听地址），它会悄悄回退到标准 net 库——这是线上 QPS 掉一半最常见的坑。
- 错误写法：
server.New(server.WithHostPorts("0.0.0.0:8080"))→ 暗中使用standard.NewTransporter - 正确写法：
server.New(server.WithHostPorts("0.0.0.0:8080"), server.WithTransport(netpoll.NewTransporter)) - TLS 场景例外：如果启用了 HTTPS，
Netpoll不支持 TLS handshake 卸载，此时必须切回standard.NewTransporter，否则 panic 报错"tls: first record does not look like a TLS handshake"
路由注册别碰 BindAndValidate 在 hot path 上
高频接口（如 /health、/metrics、/ping）若用 c.BindAndValidate(&req)，会触发反射 + JSON 解析 + struct tag 遍历，实测比裸 c.PostArgs() 慢 3–5 倍。这不是 bug，是设计取舍：验证强、性能弱。
- 对纯探针或透传类路由，直接读原始字节：
c.Request.Body()或c.QueryArgs().GetString("id") - 需要结构化校验的业务接口，才用
BindAndValidate；且确保req结构体字段加json:tag，避免 runtime reflect.LookupField - 注意：
BindAndValidate默认只处理application/json和application/x-www-form-urlencoded，不支持multipart/form-data—— 上传场景得手写c.MultipartForm()
中间件链顺序影响并发吞吐
Hertz 中间件是链式执行，每个中间件都包裹下一个；越靠前的中间件，被每请求执行的次数越多。日志、Trace 注入这类「必走」逻辑放前面没问题，但带锁、DB 连接池预检、JWT 解密这种重操作，必须往后挪。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 推荐顺序：
Recovery→Tracing→RateLimit→Auth→业务 Handler -
RateLimit放Auth后：未认证请求不该计入限流 quota，否则恶意刷 token 会导致合法用户被误限 - 自定义中间件若调用
c.Abort()提前终止，后续中间件不会执行 —— 但已进入的中间件仍占用 goroutine，所以 Abort 前尽量做轻量判断
Client 端复用连接池比 Server 端更关键
很多人盯着 Server QPS，却忽略 Hertz Client 在内部服务调用链里的瓶颈。默认 client.NewClient() 是无连接池的，每次请求新建 TCP 连接，TIME_WAIT 爆满后直接卡死。
- 必须设置：
client.NewClient(client.WithMaxConnsPerHost(1000), client.WithMaxIdleConnsPerHost(100)) - 连接池大小不能硬编码：K8s 下 Pod IP 变更频繁，建议配合
client.WithDialer(netpoll.NewDialer())使用，利用Netpoll的连接复用能力 - 超时配置要分层：
WithTimeout(3 * time.Second)控制总耗时，WithDialTimeout(500 * time.Millisecond)单独控建连，避免 DNS 慢拖垮整条链
真正卡住高并发的，往往不是单次 handler 多慢，而是连接建立、TLS 握手、DNS 解析这些前置环节没压住。Netpoll 解决了 Server 端的 goroutine 泛滥，但 Client 端的连接管理，得你自己亲手拧紧。
