默认 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）。只在以下情况值得切换：
立即学习“go语言免费学习笔记（深入）”；
- 纯内部服务，且 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 分配结构体，比换框架更稳。
