为什么是 Hertz，而不是 Gin
Go 生态里做 HTTP 服务，Gin 是事实上的默认答案。这个骨架没有选它，原因不在 API 好不好用，而在网络模型——面对高并发连接时，两者的资源模型不一样。
Hertz 是字节跳动开源的 Go HTTP 框架，底层是自研的 netpoll，走非阻塞 I/O，扛住了字节内部大量线上流量。
Gin 架在标准库 net/http 之上。 这决定了它的连接模型：一个连接对应一个 goroutine，请求的读写、等待、处理都在这个 goroutine 里完成。这是 Go 最经典也最省心的写法。
Hertz 不走 net/http，网络层是自研的 netpoll。 netpoll 用 epoll/kqueue 做事件驱动，由少量事件循环 goroutine（数量与 CPU 核数相关）统一管理所有连接，连接的读写由 I/O 事件驱动，不靠"一连接一 goroutine"堆出来。
