如何使用Go语言goroutine实现请求聚合处理-Golang-PHP中文网

goroutine泄漏导致请求聚合失败的典型表现是HTTP请求长时间无响应、runtime.NumGoroutine()持续上升、pprof显示大量goroutine停在select或chan receive；根本原因是未约束goroutine生命周期，如channel未关闭、超时后未退出、未绑定context.Context。

如何使用go语言goroutine实现请求聚合处理

goroutine 泄漏导致请求聚合失败的典型表现

用 goroutine 做请求聚合时，最常遇到的不是“没聚合”，而是“聚合了一半就卡住”或“内存持续上涨”。这往往是因为未对 goroutine 生命周期做约束，比如用 for range 读取 channel 却没关闭它，或等待超时后没主动退出 goroutine。现象包括：HTTP 请求长时间无响应、runtime.NumGoroutine() 持续上升、pprof 显示大量 goroutine 停在 select 或 chan receive。

关键原则是：每个启动的 goroutine 必须有明确退出路径，且不能依赖 GC 回收——它不会帮你关掉正在阻塞的 goroutine。

所有用于并发请求的 goroutine 都应绑定 context.Context，并在 ctx.Done() 触发时立即返回
避免直接 go fn() 启动匿名函数；优先封装为带 ctx 参数的可取消函数
聚合用的接收 channel 不要用 make(chan T)（无缓冲），而用 make(chan T, N)，N 至少等于预期并发请求数，否则第一个 goroutine 就会阻塞在发送上

用 sync.WaitGroup + channel 实现基础聚合模式

这是最可控、不依赖第三方库的写法。核心是用 sync.WaitGroup 确保所有请求 goroutine 启动完毕，再用带缓冲的 channel 收集结果，最后统一关闭 channel 并 range 消费。

func aggregateRequests(ctx context.Context, urls []string) ([]Result, error) {
    ch := make(chan Result, len(urls))
    var wg sync.WaitGroup
<pre class="brush:php;toolbar:false;">for _, url := range urls {
    wg.Add(1)
    go func(u string) {
        defer wg.Done()
        select {
        case <p>}</p>

注意：wg.Wait() 必须在 close(ch) 前调用，否则可能因 channel 未关闭导致 range 永久阻塞；但也不能把 close(ch) 放在主 goroutine 里——那会提前关闭，漏掉还在执行的 goroutine 的结果。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

timeout 和 cancel 对聚合结果完整性的影响

聚合场景下，超时不等于失败。你通常希望“尽力获取”，即：已发出的请求继续跑完，新请求不再发起，已超时的则丢弃结果。直接用 context.WithTimeout 是不够的——它会中断所有子 goroutine，包括那些已经发出去、正在等响应的 HTTP 请求。

对每个请求单独套一层 context.WithTimeout(childCtx, reqTimeout)，而不是共用一个父 timeout ctx
聚合主逻辑用 context.WithCancel，由 time.AfterFunc 或 select 超时触发 cancel()，只终止未开始的请求
不要在 fetchURL 内部忽略 ctx.Err()；HTTP client 必须传入该 ctx，否则 timeout 不生效
结果切片长度可能小于输入 URL 数量，需检查 Result.Err 字段区分是失败还是被跳过

并发数控制不当引发连接池耗尽

不做限制地为每个 URL 启 goroutine，容易打爆 http.DefaultTransport 的连接池（默认 MaxIdleConnsPerHost=100）。现象是大量请求卡在 net/http.Transport.roundTrip，日志里反复出现 dial tcp: lookup xxx: no such host 或 context deadline exceeded 却不是真超时。

解决方式不是减少 goroutine 数量，而是复用 transport 并显式限流：

自定义 http.Transport，设 MaxIdleConnsPerHost ≥ 预期并发数
用 semaphore（如 golang.org/x/sync/semaphore）或带缓冲 channel 控制并发请求数，例如 sem := semaphore.NewWeighted(20)
在每个 goroutine 开头 sem.Acquire(ctx, 1)，结尾 sem.Release(1)
避免在循环里重复创建 http.Client；全局复用一个 client 实例