net/http 默认客户端拖慢高并发请求，因 transport 配置保守：空闲连接数少、超时短、无预热；应调大 maxidleconns 等参数、延长 idleconntimeout、预热 dns 并合理设置 dialer 超时。
为什么 net/http 默认客户端会拖慢高并发请求
Go 的 http.DefaultClient 默认复用连接，但它的 Transport 配置偏保守：最大空闲连接数低、空闲连接超时短、无连接池预热。在突发流量或短连接密集场景下，频繁建连、TLS 握手、DNS 解析会显著抬高 P95 延迟。
实操建议：
- 显式配置
http.Transport，把MaxIdleConns和MaxIdleConnsPerHost设为足够大（如 100 或 200），避免连接被过早关闭 - 将
IdleConnTimeout提高到 30–90 秒，匹配后端服务的 keep-alive 设置 - 启用
ForceAttemptHTTP2（默认已开启），确保复用 HTTP/2 流而非新建 TCP 连接 - 若调用固定域名，可预热 DNS 缓存：
net.DefaultResolver.PreferGo = true并配合net.Resolver.LookupHost提前解析
如何避免 time.Sleep 和同步阻塞放大网络延迟
在 HTTP 处理逻辑中写 time.Sleep(100 * time.Millisecond) 看似无害，但在高并发下会直接卡住 goroutine 调度器，导致后续请求排队——这不是网络延迟，却是用户感知到的“变慢”。
常见错误现象：pprof 显示大量 goroutine 停留在 runtime.gopark，http.Server 的 Handler 耗时突增但下游服务日志无异常。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 用
context.WithTimeout控制单次请求总耗时，而非在 handler 中 sleep - 异步任务（如日志上报、埋点）必须用
go func() { ... }()启动，且避免无缓冲 channel 阻塞 - 若需限流，优先用
golang.org/x/time/rate.Limiter，它不阻塞主流程，只控制 token 获取时机
net.Dialer 的超时设置为何比 http.Client.Timeout 更关键
http.Client.Timeout 只覆盖整个请求生命周期（DNS + dial + TLS + write + read），一旦连接已建立，它对读写阶段的卡顿无效。真正影响建连阶段的是底层 net.Dialer 的三个超时字段。
实操建议：
- 自定义
http.Transport时，务必设置DialContext函数，并在其中指定&net.Dialer{Timeout: 3 * time.Second, KeepAlive: 30 * time.Second} - 避免设过长的
Timeout（如 30s），否则失败连接会占用连接池长达数十秒，挤占健康连接资源 - 若后端部署在 Kubernetes 内，可加
Resolver缓存 DNS 结果，减少每次 dial 前的getaddrinfo系统调用
何时该换掉 net/http 改用 fasthttp 或 gnet
fasthttp 在纯吞吐场景（如 API 网关、反向代理）确实能压测出更高 QPS，但它不兼容标准 net/http 接口，且对中间件生态支持弱；gnet 更底层，适合自研协议网关，但开发成本陡增。
是否值得切换，取决于真实瓶颈：
- 用
go tool trace观察：如果netpoll占比高、goroutine 频繁 park/unpark，说明 I/O 调度是瓶颈，fasthttp可能有收益 - 如果
runtime.mallocgc或runtime.scanobject占比高，问题在内存分配（如频繁构造http.Request），此时优化结构体复用比换框架更有效 - 若延迟毛刺集中在 TLS 握手阶段，应优先考虑
crypto/tls的GetConfigForClient复用 session ticket，而非换 HTTP 库
多数业务服务的延迟瓶颈不在 HTTP 库本身，而在下游依赖、序列化开销或锁竞争。盲目替换反而增加维护复杂度和调试成本。
