sync.WaitGroup 是 Go 中控制并发请求生命周期最轻量方式，需在启动 goroutine 前调用 wg.Add(n)，每个 goroutine 入口 defer wg.Done()，配合 context.WithTimeout 统一超时管理，并用 channel 汇总结果。
Go 中用 sync.WaitGroup 控制并发请求生命周期
直接用 go 启动一堆 goroutine 发请求，不等它们结束就返回，结果必然丢数据。核心是让主 goroutine 知道“所有请求都完成了”。sync.WaitGroup 是最轻量、最常用的方式，别用 channel 去“数完成数”，容易漏 Done() 或多调用。
常见错误：在 goroutine 里 defer wg.Done()，但忘了把 wg.Add(1) 放在启动前——导致 Wait() 永远阻塞；或者把 wg.Add(n) 放在循环内却没加锁，引发 panic。
-
wg.Add(len(urls))必须在 for 循环启动 goroutine 之前一次性调用 - 每个 goroutine 入口第一行写
defer wg.Done()，确保无论成功失败都计数减一 - 不要在 goroutine 内部再调
wg.Add()，除非你明确要动态扩增任务数
用 context.WithTimeout 统一控制批量请求超时
单个请求设超时（如 http.Client.Timeout）只管自己，但批量场景下更关键的是“整批最多耗时多久”。比如 100 个请求，单个 5s，但业务只给 8s 总时间——必须用 context.WithTimeout 包裹整个并发块，否则可能卡住主流程。
注意：http.Client 的 Timeout 字段和 context 超时会叠加生效，优先触发者 cancel 请求。建议关掉 client 自身 timeout（设为 0），全交给 context 管理，逻辑更清晰。
立即学习“go语言免费学习笔记（深入）”；
- 创建
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second) - 每个
http.NewRequestWithContext(ctx, ...)都传这个 ctx - 务必在函数退出前调
cancel()，避免 goroutine 泄漏（尤其在提前 return 时）
结果汇总推荐用 chan + for range 收集，别用切片加锁
多个 goroutine 往同一个 []Result 写，就得加 sync.Mutex，但锁竞争反而拖慢吞吐。更 Go 的做法是每个 goroutine 把结果发到一个共享 channel，主 goroutine 用 for i := 0; i 或带 <code>select 的超时接收来收齐。
channel 容量建议设为 len(urls)（缓冲 channel），避免 sender 因 receiver 暂未读而阻塞；如果结果结构体较大，考虑用指针 chan *Result 减少拷贝。
- 声明
ch := make(chan Result, len(urls)) - 每个 goroutine 最后写
ch （不是 <code>ch ，除非你要改原值） - 主 goroutine 用
for i := 0; i 顺序无关地收结果
错误处理别忽略 http.Do 返回的 error 和 resp.StatusCode
很多人只检查 err != nil，但 http.Do 成功返回 *http.Response 后，resp.StatusCode 可能是 4xx/5xx —— 这类响应体里往往有错误信息，不读取就丢掉了。批量请求中，一个 401 不影响其他请求，但你不处理，后续解析 JSON 就 panic。
典型坑：用 json.NewDecoder(resp.Body).Decode(&v) 前没检查 resp.StatusCode >= 200 && resp.StatusCode ，结果把 HTML 错误页当 JSON 解了。
- 先判断
err != nil（网络层失败） - 再判断
resp.StatusCode = 300（业务层失败） - 两种错误都应构造统一
Result{URL: url, Err: err, Data: nil}发回 channel
并发批量请求真正难的不是发出去，而是怎么让错误不掩盖成功、超时不拖垮整体、结果不乱序又不丢——这些细节堆起来，才决定接口调用是否可靠。
