17370845950

默认 http.Server 响应慢主因是未调优的连接复用、TLS开销、WriteHeader时机不当、日志阻塞及无缓冲ResponseWriter；必设ReadTimeout、WriteTimeout、IdleTimeout和ConnState回调优化，可提升20%+ P95延迟。

为什么默认的 http.Server 响应慢？

不是代码写得不够快，而是默认配置在高并发或小响应体场景下容易暴露瓶颈：连接复用未显式控制、TLS握手开销被忽略、WriteHeader 调用时机不当导致缓冲区提前 flush、日志中间件阻塞主线程。尤其当响应体小于 1KB 且 QPS > 1000 时，http.Server 默认的 ReadTimeout/WriteTimeout 和无缓冲的 ResponseWriter 会放大延迟抖动。

http.Server 必设的 4 个性能参数

不改代码逻辑，仅调整 http.Server 实例字段就能压测提升 20%+ P95 延迟：

• ReadTimeout 和 WriteTimeout 必须设置（哪怕设为 30 * time.Second），否则内核 socket 读写可能无限等待，拖垮整个连接池
• IdleTimeout 设为 60 * time.Second —— 太短（如 5s）会导致 HTTP/1.1 Keep-Alive 连接频繁重建；太长（如 5m）则空闲连接占满 ulimit -n
• MaxConnsPerHost 不影响 server 端，但如果你用 http.Client 做后端调用，必须同步调大该值，否则 client 端连接池打满会阻塞请求
• ConnState 回调里别做任何 IO 或锁操作，只记录连接状态变化；曾有团队在这里加了 log.Printf，QPS 直降 40%

避免 ResponseWriter 的隐式 flush

Go 的 http.ResponseWriter 在写入超过 2048 字节或调用 WriteHeader 后会自动 flush，但小响应（如 JSON API 返回 {"ok":true}）若未显式控制，可能触发多次 tiny write，增加 syscall 次数。正确做法是：

• 总是先调用 w.WriteHeader(statusCode)，再写 body；不要依赖默认 200
• 对已知小响应（bytes.Buffer 预拼接，一次性 w.Write(buf.Bytes())，避免多次 write 系统调用
• 禁用 http.ServeMux 自带的 directory listing（它会在 404 时尝试读文件系统），生产环境一律用显式路由

func handler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(http.StatusOK)
    // ✅ 预分配 buffer，避免多次 write
    buf := make([]byte, 0, 32)
    buf = append(buf, `{"ok":true}`...)
    w.Write(buf)
}

什么时候该换 fasthttp？

fasthttp 不是银弹。它通过零拷贝、复用 RequestCtx、跳过 net/http 的 http.Header map 构建来提速，但代价是不兼容标准库生态（比如不能直接用 gorilla/mux 或 chi）。只在以下情况值得切换：

• 纯内部服务，且 95% 请求是 GET /health 或 POST /ingest，body 小、路径固定
• 压测发现 net/http 的 runtime.mallocgc 占 CPU > 30%，而业务逻辑简单
• 你愿意自己处理 Content-Length、Transfer-Encoding、HTTP/2 兼容等细节（fasthttp 默认不支持 HTTP/2）
• 注意：fasthttp 的 RequestCtx.PostBody() 返回的是底层 byte slice 引用，如果存到 goroutine 外部，必须 copy

  

  出来，否则数据会被复用覆盖

大多数 Web API 服务，调优 net/http.Server + 合理使用 sync.Pool 分配结构体，比换框架更稳。