默认 http.Server 高并发吞吐低因未启用 Keep-Alive、未设 IdleTimeout 导致连接堆积和 fd 耗尽，必须配置 ReadTimeout、WriteTimeout、IdleTimeout 和 MaxHeaderBytes 四个字段。
为什么默认的 http.Server 在高并发下吞吐上不去
Go 的 net/http 默认配置偏保守，http.Server 启动时不显式设置时，会使用 DefaultServeMux 和系统默认的 http.DefaultClient 行为，但真正卡吞吐的往往是连接复用、超时控制和底层 net.Listener 的行为。常见现象包括：大量请求卡在 ESTABLISHED 状态不释放、TIME_WAIT 连接堆积、CPU 利用率低但 QPS 上不去。
根本原因不是 Go 本身慢，而是默认没打开连接复用（Keep-Alive）、没限制 idle 超时、没调优底层 TCP 参数，导致连接频繁建连/断连，内核队列打满，goroutine 大量阻塞在 read 或 write 上。
必须设置的 4 个关键 http.Server 字段
只改 handler 逻辑或加 goroutine 并不能提升吞吐，关键在服务端连接生命周期管理。以下字段缺一不可：
-
ReadTimeout和WriteTimeout：防止慢客户端拖垮整个服务；建议设为5 * time.Second起步，避免长连接占用资源 -
IdleTimeout：控制 Keep-Alive 连接空闲多久后关闭；必须设（如30 * time.Second），否则连接长期 hang 住，fd 耗尽 -
MaxHeaderBytes：限制请求头大小，防攻击；设为64 （64KB）较安全 -
ConnState回调（可选但推荐）：用于监控连接状态变化，快速发现异常连接堆积
srv := &http.Server{
Addr: ":8080",
Handler: myHandler,
ReadTimeout: 5 * time.Second,
WriteTimeout: 5 * time.Second,
IdleTimeout: 30 * time.Second,
MaxHeaderBytes: 64 << 10,
}客户端侧：别用全局 http.DefaultClient
服务端作为 HTTP 客户端发起下游调用（比如调第三方 API）时，若直接用 http.DefaultClient，它的 Transport 默认 MaxIdleConns 是 100，MaxIdleConnsPerHost 是 2 —— 这是给浏览器类场景设计的，不是服务间调用。结果就是：下游服务响应稍慢，连接池迅速耗尽，后续请求排队等空闲连接，吞吐断崖下跌。
立即学习“go语言免费学习笔记（深入）”；
正确做法是为每个下游目标单独配 Transport，并调大连接池：
client := &http.Client{
Transport: &http.Transport{
MaxIdleConns: 200,
MaxIdleConnsPerHost: 200,
IdleConnTimeout: 30 * time.Second,
TLSHandshakeTimeout: 5 * time.Second,
},
}注意：MaxIdleConnsPerHost 必须显式设，否则它继承 MaxIdleConns 的值，但 Go 1.19+ 中默认为 0，实际会退化成 2。
别忽略 runtime.GOMAXPROCS 和 GC 压力
吞吐卡在 CPU 不是常态，但真发生时往往是因为：GOMAXPROCS 没随核数调整，或 JSON 解析/日志打印引发高频小对象分配，触发 GC 频繁 STW。尤其在处理大量短请求（如 JSON API）时，json.Unmarshal 每次都 new map/string，容易让堆增长过快。
实操建议：
- 启动时显式设
runtime.GOMAXPROCS(runtime.NumCPU())，避免容器环境里GOMAXPROCS仍为 1 - 用
sync.Pool缓存常用结构体或bytes.Buffer，特别是日志格式化或 JSON 序列化场景 - 压测时用
go tool pprof -http=:8081 <binary> debug/pprof/goroutine?debug=2看 goroutine 是否异常堆积在net/http.serverHandler.ServeHTTP
最易被忽略的是：即使你调优了所有 HTTP 参数，如果 handler 里有隐式同步（比如未加锁的全局 map 写入），或用了 log.Printf 打印每条请求，吞吐照样上不去——这类问题不会报错，只会让 P99 延迟悄悄翻倍。
