Go中直接for+go http.Get易致连接耗尽、超时失控、DNS反复解析，须自定义http.Transport（设MaxIdleConns/PerHost、IdleConnTimeout等）并用errgroup限并发、传错误、配单请求context超时，同时优化DNS缓存与TLS握手。
Go 的 goroutine 配合标准库 http.Client 是实现高并发 API 请求最直接、最可控的方式——但默认配置下极易触发连接耗尽、超时失控或 DNS 缓存问题。
为什么不能直接 for + go http.Get？
裸写 for range { go http.Get(...) } 看似简单，实际会快速撞上系统限制：
-
http.DefaultClient的底层http.Transport默认只允许最多100个空闲连接（MaxIdleConns），且每个 host 仅2个（MaxIdleConnsPerHost），大量 goroutine 会阻塞在连接获取上 - 没有统一超时控制，单个请求卡住会拖垮整个批次
- 无错误聚合，失败请求悄无声息丢失
- DNS 解析结果默认缓存 0 秒（Go 1.19+），高频请求可能反复解析，加剧延迟
必须自定义 http.Transport 并设置关键参数
并发请求成败几乎全取决于 http.Transport 配置。以下是最小必要配置：
transport := &http.Transport{
MaxIdleConns: 200,
MaxIdleConnsPerHost: 200,
IdleConnTimeout: 30 * time.Second,
TLSHandshakeTimeout: 10 * time.Second,
// 强制复用连接，避免频繁建连
ForceAttemptHTTP2: true,
// 可选：禁用 HTTP/2（某些老旧服务不兼容）
// TLSNextProto: make(map[string]func(authority string, c *tls.Conn) http.RoundTripper),
}注意：MaxIdleConnsPerHost 必须显式设为较大值，否则会被 MaxIdleConns 截断；IdleConnTimeout 过短会导致连接过早关闭，过长则浪费资源。
用 errgroup 控制并发数与错误传播
原生 sync.WaitGroup 无法传递错误，而 golang.org/x/sync/errgroup 提供了带错误中断的并发控制：
import "golang.org/x/sync/errgroup"g, _ := errgroup.WithContext(context.Background()) g.SetLimit(50) // 严格限制
最大并发数，防打爆目标或本地 fd
for , url := range urls { url := url // 避免闭包变量复用 g.Go(func() error { req, := http.NewRequest("GET", url, nil) req.Header.Set("User-Agent", "my-app/1.0")
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel() req = req.WithContext(ctx) resp, err := client.Do(req) if err != nil { return fmt.Errorf("request %s failed: %w", url, err) } defer resp.Body.Close() if resp.StatusCode != 200 { return fmt.Errorf("request %s returned %d", url, resp.StatusCode) } return nil })}
if err := g.Wait(); err != nil { log.Printf("at least one request failed: %v", err) }
关键点：
g.SetLimit(n)是硬性闸门；context.WithTimeout必须套在每个请求上，不能只套在外层；req.WithContext()才能真正中断正在执行的请求。别忽略 DNS 和 TLS 层的隐性瓶颈
即使 HTTP 层调优到位，DNS 查询和 TLS 握手仍可能成为并发瓶颈：
- Go 默认使用系统 DNS（如
getaddrinfo），在 Linux 上可能受/etc/resolv.conf中options timeout:影响；可考虑用net.Resolver配合内存缓存（如dnscache库） - TLS 握手耗时波动大，
TLSHandshakeTimeout必须显式设置，否则默认为 0（无限等待） - 若请求目标固定且可信，可复用
*tls.Config并启用SessionTicketsDisabled: false加速复用
真实压测中，未调优 DNS/TLS 的吞吐量可能只有调优后的 1/3，这点常被忽略。
