最稳妥的并发控制方式是用 goroutine + sync.WaitGroup 配合信号量（chan struct{}）限流，并配置 http.Client 超时与 Transport 连接复用参数，且每次请求后必须调用 resp.Body.Close()。
用 goroutine + sync.WaitGroup 控制并发数量最稳妥
盲目起成百上千个 goroutine 发请求，容易打垮目标服务或触发本地文件描述符耗尽（too many open files）。必须显式限流。常见错误是只用 go http.Get(...) 不加控制，结果程序卡死或报错。
推荐做法：用 sync.WaitGroup 等待所有请求完成，配合带缓冲的 chan struct{} 或 semaphore 控制并发数。不依赖第三方库，标准库足够。
- 并发数建议设为 10–50，具体看目标服务承受力和本地资源
- 每个
goroutine必须有自己的*http.Client实例或复用同一个（但注意Client.Timeout是全局的） - 务必调用
resp.Body.Close()，否则连接不释放，很快触发too many open files
func doRequests(urls []string, maxConcurrent int) {
sem := make(chan struct{}, maxConcurrent)
var wg sync.WaitGroup
for _, url := range urls {
wg.Add(1)
go func(u string) {
defer wg.Done()
sem <- struct{}{} // 获取信号量
defer func() { zuojiankuohaophpcn-sem }() // 释放
resp, err := http.Get(u)
if err != nil {
log.Printf("GET %s failed: %v", u, err)
return
}
defer resp.Body.Close() // 关键！
body, _ := io.ReadAll(resp.Body)
log.Printf("GET %s ok, len=%d", u, len(body))
}(url)
}
wg.Wait()}
http.Client 的 Timeout 和 Transport 需要手动配置
默认的 http.DefaultClient 没有设置超时，遇到网络卡顿或服务无响应，goroutine 会无限阻塞，拖垮整个并发池。同时，默认的 Transport 连接复用参数偏保守，高并发下容易堆积 idle 连接。
立即学习“go语言免费学习笔记（深入）”；
-
Client.Timeout控制整个请求生命周期（DNS + 连接 + 写请求 + 读响应），建议设为 10–30 秒 -
Transport.MaxIdleConns和MaxIdleConnsPerHost建议调大（如 100），避免频繁建连 -
Transport.IdleConnTimeout设为 30 秒，防止长连接被服务端断开后还留在池里
client := &http.Client{
Timeout: 15 * time.Second,
Transport: &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
IdleConnTimeout: 30 * time.Second,
},
}用 context.WithTimeout 替代全局 Client.Timeout 更灵活
当一批请求中部分需要更短超时（比如健康检查 2 秒超时，数据拉取 15 秒），用全局 Client.Timeout 就不够用了。此时应把 context.Context 传入 client.Do(req)，实现 per-request 超时控制。
- 不能直接对
http.Get用 context，得构造*http.Request后调用client.Do - 注意：context 超时会取消请求，但底层 TCP 连接可能还在，
Transport会自动处理复用或关闭 - 如果用了自定义
RoundTripper，需确保它尊重req.Context().Done()
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
resp, err := client.Do(req)
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
log.Printf("request %s timed out", url)
}
return
}别忽略 DNS 解析和 TLS 握手的耗时与失败场景
并发发请求时，DNS 解析失败（lookup xxx: no such host）或 TLS 握手失败（remote error: tls: bad certificate）会直接返回错误，但这类错误常被当成业务错误忽略，实际是基础设施问题。
- DNS 缓存：Go 默认不缓存 DNS 结果，高频请求可考虑用
net.Resolver+ 本地 cache，或改用dnsserver代理 - TLS 验证失败：测试环境用自签名证书时，需定制
Transport.TLSClientConfig.InsecureSkipVerify = true（仅限调试） - 连接拒绝（
connection refused）或超时（i/o timeout）要区分是网络层还是服务层问题，日志里保留原始错误类型
真正难调的不是并发逻辑本身，而是超时组合、连接复用策略、错误分类这三者的交织。一个没关的 Body，可能让后续几百个请求全卡住；一个没设的 IdleConnTimeout，可能让服务在低 QPS 下缓慢泄漏连接。这些细节比 goroutine 怎么写重要得多。
