Go网络请求优化需复用连接、控制并发、设置超时、选合适协议：自定义http.Client调优Transport参数，用context设分级超时，限流防压垮，内部通信优先gRPC，避免JSON解析瓶颈。
在 Go 中优化网络请求，核心是减少阻塞、复用连接、合理控制并发，并避免常见反模式。Go 的 net/http 默认已较高效，但默认配置并不适合所有场景——尤其高并发、低延迟或大量外部调用的系统。
复用 HTTP 连接（启用连接池）
HTTP/1.1 默认支持长连接，但 Go 的 http.Client 不会自动复用连接，除非你显式配置 Transport。默认的 http.DefaultClient 使用的 Transport 对连接数限制较保守（如 MaxIdleConnsPerHost = 2），容易成为瓶颈。
建议自定义 http.Client 并调优 Transport：
-
增大空闲连接数：设置
MaxIdleConns和MaxIdleConnsPerHost（例如 100 或更高，视服务端承受力而定） -
设置连接存活时间：
IdleConnTimeout控制空闲连接复用时长（推荐 30–90 秒） -
禁用 HTTP/2（必要时）：某些代理或老旧服务对 HTTP/2 支持不完善，可设
ForceAttemptHTTP2 = false
示例：
立即学习“go语言免费学习笔记（深入）”；
client := &http.Client{Transport: &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
IdleConnTimeout: 30 * time.Second,
TLSHandshakeTimeout: 5 * time.Second,
},
}
设置合理的超时与上下文控制
没有超时的请求会无限等待，拖垮 goroutine 和连接池。必须为每个请求设置明确的生命周期边界。
推荐使用 context.WithTimeout 或 context.WithDeadline，而非仅依赖 http.Client.Timeout（它只覆盖整个请求周期，不涵盖 DNS 解析、TLS 握手等前置阶段）：
- DNS 解析、TCP 建连、TLS 握手、首字节响应 —— 各阶段都可能卡住，建议用
context.WithTimeout统一兜底 - 对下游服务分级设超时：核心接口 200ms，非关键接口 1s，批量任务可放宽
- 避免在 handler 中直接传
context.Background()；优先从入参 context 派生子 context
控制并发量，避免压垮自身或下游
盲目开大量 goroutine 发请求，易触发文件描述符耗尽、TIME_WAIT 泛滥、或把下游打挂。需主动限流。
- 用带缓冲的 channel 或
semaphore（如golang.org/x/sync/semaphore）限制并发请求数 - 对同一目标域名，可结合
MaxConnsPerHost防止单点过载 - 考虑使用熔断器（如
sony/gobreaker）+ 重试退避（backoff库），避免雪崩
简单并发控制示例：
sem := semaphore.NewWeighted(10) // 最多 10 并发for _, url := range urls {
if err := sem.Acquire(ctx, 1); err != nil {
break
}
go func(u string) {
defer sem.Release(1)
resp, _ := client.Get(u)
}(url)
}
选择合适协议与序列化方式
HTTP 并非万能。若内部微服务通信，延迟敏感场景可考虑：
- gRPC over HTTP/2：二进制编码 + 流式传输 + 多路复用，比 JSON over HTTP 更省带宽、更低延迟
- 连接复用 + 管道化（慎用）：HTTP/1.1 管道化因服务端支持差、队头阻塞严重，基本不推荐
-
避免大 Payload 同步传输：上传大文件改用分块 + 预签名 URL；下载大响应考虑流式读取（
io.Copy）+ 边读边处理
另外，JSON 解析（json.Unmarshal）较慢，高频场景可换 easyjson、ffjson 或 msgpack 等更高效的编解码器。
