Go 高性能 HTTP 服务：fasthttp 与标准库 net/http 的性能对比

如果你写过一段时间 Go 服务，大概率会遇到这个经典问题：为什么 fasthttp 的压测数字那么漂亮，网上很多对比都说它比标准库 net/http 快好几倍，但很多项目最终还是选择 net/http？这个问题背后不单纯是性能，而是一组工程取舍。这篇博客我会从实现机制、真实场景和踩坑经验三个角度，把 fasthttp 与标准库 net/http 的差异讲清楚。

先给一个基本判断：在极端压测场景下，fasthttp 确实通常比 net/http 有更高的吞吐和更低的内存占用，尤其在高并发、短请求、响应体小的场景下。但这个“快”来自它刻意牺牲了标准库的兼容性和通用性。如果你在业务 API 里盲目替换，很可能会发现性能没提升多少，开发和维护成本却上去了。

为什么 fasthttp 看起来快很多

标准库 net/http 的实现模型是：每个连接启动一个 goroutine，连接期间所有请求都在这个 goroutine 里处理。这个模型简单、稳定，也符合 Go 的并发哲学。但它有几个开销点：

• 高并发连接数下，goroutine 数量线性增长，调度和内存开销都上去了。
• 每个连接内部还有一层缓冲、超时控制、请求解析的抽象，有些操作会触发额外内存分配。
• handler 的接口是 http.Handler，请求数据要封装成 http.Request，响应要经过 http.ResponseWriter，这些抽象在每次请求时都有成本。

fasthttp 的做法完全不同。它维护一个固定大小的 worker goroutine 池，所有连接复用这些 goroutine。同时，它使用 sync.Pool 复用 RequestCtx，避免每次请求都分配对象。它还重新实现了请求解析、连接管理和缓冲策略，减少了很多系统调用和数据拷贝。

有一个关键差异值得注意：net/http 在每次请求时创建的 http.Request 和 http.ResponseWriter 是相对“重”的对象，而 fasthttp 的 RequestCtx 几乎可以完全复用，所以内存分配次数会少一个数量级。在高并发短请求场景下，这个差距会被放大。

不过，真正的工程场景往往不是纯粹的 Hello World。业务处理、数据库访问、JSON 序列化，这些环节的开销很容易超过 HTTP 层本身。只要业务逻辑超过 1ms，fasthttp 带来的几百微秒提升可能就不明显了。

标准库 net/http 被低估的地方

很多人只拿压测数字说事，却忽略了标准库的很多优点。

首先是 HTTP/2。net/http 原生支持 HTTP/2，包括 h2c，而且随着 Go 版本升级，对 HTTP/2 的支持越来越完善。fasthttp 目前对 HTTP/2 的支持仍然有限，官方主要聚焦 HTTP/1.1。如果你的服务需要处理 gRPC 或者需要浏览器 HTTP/2 复用，fasthttp 会非常尴尬。

其次是生态。net/http 是 Go 社区所有 web 框架的基础，gin、echo、chi 都是基于它或兼容它的接口。这意味着中间件、日志、追踪、限流等组件可以无缝复用。而 fasthttp 的 handler 签名完全不同，社区里现成的中间件大多不兼容，很多都要自己写。

还有一个容易忽略的点：标准库的性能也可以通过合理配置优化。比如设置合理的超时和缓冲区参数，能显著减少连接占用和资源浪费。

srv := &http.Server{
    Addr:         ":8080",
    ReadTimeout:  5 * time.Second,
    WriteTimeout: 10 * time.Second,
    IdleTimeout:  30 * time.Second,
    MaxHeaderBytes: 1 << 20,
}
srv.ListenAndServe()

这里的关键是 ReadTimeout 和 WriteTimeout 避免慢客户端长时间占用连接，IdleTimeout 控制 keep-alive 连接的空闲回收。很多性能问题不是 net/http 本身慢，而是连接被慢请求拖住。

另外，net/http 的 http.Client 连接池行为也比很多开发者预期的要好。默认情况下它就会复用底层连接，只要正确配置 MaxIdleConns 和 MaxIdleConnsPerHost，也能达到不错的连接复用效果。

fasthttp 的代价：不兼容与陷阱

fasthttp 的优化思路决定了它必然付出一些代价，这些代价在项目里会表现为实实在在的坑。

最明显的就是 API 不兼容。net/http 的 handler 接收 http.ResponseWriter 和 *http.Request，fasthttp 的 handler 接收 *fasthttp.RequestCtx。如果你的业务代码里大量依赖 context.Context 传递超时和链路信息，那么必须自己手动从 ctx 里构造 context，或者使用 fasthttp/adaptor 把标准 handler 转成 fasthttp handler，但这层转换本身又有额外开销。

另一个典型的坑是对象复用。fasthttp 的 RequestCtx 在处理完请求后会被放回池中，如果你把 ctx 的某个字段引用存到全局或者异步 goroutine 里，数据很快会被覆盖。这意味着你必须在请求结束前把需要的值拷贝出来。这一点和 net/http 的 http.Request 完全不同，后者在 handler 返回后仍然可以安全读取。

此外，fasthttp 对 HTTP/2 的支持不够，也不支持 WebSocket（如果使用标准库的 WebSocket 实现）。对于需要这些能力的项目，基本只能放弃 fasthttp。

还有一点常被忽略：fasthttp 的请求解析为了追求速度，对某些 HTTP 行为的处理不如标准库严格。比如它默认不支持 chunked 请求体？其实支持，但有些边界行为可能有差异。在生产环境里，兼容性比性能更难排查。

下面用一段代码展示两者 handler 写法的差异：

// net/http
http.HandleFunc("/hello", func(w http.ResponseWriter, r *http.Request) {
    name := r.URL.Query().Get("name")
    fmt.Fprintf(w, "Hello, %s", name)
})

// fasthttp
func hello(ctx *fasthttp.RequestCtx) {
    name := ctx.QueryArgs().Peek("name")
    fmt.Fprintf(ctx, "Hello, %s", name)
}
fasthttp.ListenAndServe(":8080", hello)

从代码层面看，似乎差别不大，但 ctx 的生命周期和接口能力与 net/http 完全不同。业务代码越复杂，这种差异带来的迁移成本越高。

真实场景下怎么选

与其纠结 benchmark 数字，不如先想清楚自己的服务属于哪种类型。我见过几类比较典型的场景：

• 一个在线广告接口，单机峰值 QPS 非常高，响应体很小，业务逻辑简单，这种场景 fasthttp 的收益最明显。
• 一个微服务网关，需要维护大量长连接，标准库的 goroutine 数量会随连接数线性增长，内存压力大。fasthttp 的连接处理模型能明显降低内存占用。
• 一个业务 API，每次请求要查数据库、调用下游，整体耗时几十毫秒。这种情况下，fasthttp 带来的性能提升几乎可以被忽略，反而会因为 API 不兼容增加团队的学习成本。

下表从几个关键维度做个对比，方便你判断自己的场景：

如果你的服务是典型的业务 API，我会直接建议先用标准库。除非压测结果明确显示 net/http 的 goroutine 模型或内存分配成为瓶颈，否则没有必要为了一个看起来很美的数字去引入兼容性问题。

如果要上 fasthttp，怎么避坑

如果经过评估确实需要 fasthttp，建议从边缘服务开始试点，比如内部代理、接口网关，而不是直接替换核心业务。同时，这几个问题要提前想好：

1. 确认请求体和响应体的生命周期。不要把 RequestCtx 里的数据传给异步任务，或者需要时先拷贝到独立变量。
2. 考虑使用 fasthttp/adaptor 临时兼容 net/http 中间件，但要注意这层转换会带来额外开销，最好还是直接实现 fasthttp 版本的中间件。
3. 监控内存和 goroutine 数量，不要只盯着 QPS。fasthttp 的 worker 池和对象复用可能掩盖一些内存泄漏问题，要结合 pprof 做分析。
4. 注意超时控制。fasthttp 的 Server 也有 ReadTimeout、WriteTimeout 等配置，务必设置，否则慢连接会拖垮整个 worker 池。

还有一个实际建议：把 fasthttp 当作一个优化手段，而不是默认选择。很多团队在业务初期就用 fasthttp，结果到后期发现需要接 OpenTelemetry、需要 HTTP/2 时，处处受制。先跑标准库，等真正遇到性能瓶颈，再针对热点接口做优化，可能更稳妥。

最后我想说，性能对比永远离不开具体场景。fasthttp 和 net/http 都是经过大量验证的成熟实现，没有绝对的优劣，只有是否适合。理解了它们各自的取舍，你就能在高性能 HTTP 服务的选型里更有底气。