本文详解 Go 中并发执行 HTTP 请求的常见误区，重点指出 wg.Wait() 位置错误导致伪并发问题，并提供正确、可扩展的并发实现方案及性能优化建议。
本文详解 go 中并发执行 http 请求的常见误区，重点指出 `wg.wait()` 位置错误导致伪并发问题，并提供正确、可扩展的并发实现方案及性能优化建议。
在 Go 中使用 goroutine 实现并发看似简单，但一个细微的同步逻辑错误就足以让并发退化为串行——这正是你遇到性能无提升甚至变慢的根本原因。
你的“Go Routine 版本”实际并未并发执行请求，而是逐个启动 goroutine 并立即阻塞等待其完成：
for i := 0; i < 250; i++ {
wg.Add(1)
go run(url, &wg)
wg.Wait() // ⚠️ 错误：每次循环都等待前一个 goroutine 结束
}wg.Wait() 在循环体内调用，意味着第 i+1 个 goroutine 要等到第 i 个完全执行完毕（包括网络 I/O、响应处理）后才启动。整个流程仍是线性串行，且额外承担了 goroutine 创建、调度和 sync.WaitGroup 的开销，因此比单协程版本更慢。
✅ 正确做法是：先批量启动所有 goroutine，再统一等待全部完成：
func main() {
url := "https://httpbin.org/get" // 推荐使用稳定测试地址（原 Yahoo URL 已失效且含重定向）
var wg sync.WaitGroup
for i := 0; i < 250; i++ {
wg.Add(1)
go func(u string) {
defer wg.Done()
resp, err := http.Get(u)
if err != nil {
fmt.Printf("Request failed: %v\n", err)
return
}
defer resp.Body.Close()
fmt.Println(resp.Status)
}(url)
}
wg.Wait() // ✅ 正确：所有 goroutine 启动完毕后，一次性等待全部结束
}⚠️ 注意事项与进阶建议：
- 避免变量捕获陷阱：示例中使用 go func(u string) 传参，防止循环变量 url 在闭包中被后续迭代覆盖（经典 for + go 闭包问题）；
- 务必关闭响应体：defer resp.Body.Close() 防止文件描述符泄漏，尤其在高并发下至关重要；
-
控制并发规模：盲目启动 250 个 goroutine 可能压垮客户端或服务端。生产环境应使用带缓冲的 channel 或 semaphore 限流，例如限制最多 20 个并发请求：
sem := make(chan struct{}, 20) for i := 0; i < 250; i++ { sem <- struct{}{} // 获取令牌 go func() { defer func() { <-sem }() // 归还令牌 // 执行请求... }() } // 等待所有 goroutine 完成（配合 WaitGroup） - 考虑使用 errgroup：标准库 golang.org/x/sync/errgroup 可自动传播首个错误并优雅等待，代码更健壮；
- 基准测试需排除干扰：真实性能对比应使用 go test -bench，禁用 GC 干扰，并多次运行取平均值；同时注意目标服务端限流、DNS 解析、TCP 连接复用（http.DefaultClient.Transport 默认启用 Keep-Alive）等外部因素。
总结：并发 ≠ 多个 goroutine，而在于重叠等待时间。HTTP 请求本质是 I/O 密集型操作，真正的并发收益来自让多个请求的网络等待期相互重叠。只有解除同步阻塞、合理管控资源，才能释放 Go 并发模型的强大能力。
