Golang并发下载任务的实现方案

sync.WaitGroup 是控制并发下载生命周期最直接轻量的方式,需在启动 goroutine 前调用 wg.Add(1),wg.Done() 放 defer 中,主 goroutine 调用 wg.Wait() 阻塞等待;限流用带缓冲 channel,失败重试需区分错误类型并归集,文件写入须各 goroutine 独立操作。

sync.WaitGroup 控制并发下载的生命周期

并发下载的核心不是“开很多 goroutine”,而是“等所有下载完成再退出”。sync.WaitGroup 是最直接、最轻量的方式,避免用 time.Sleep 硬等或手动计数出错。

  • 必须在启动 goroutine 前调用 wg.Add(1),不能在 goroutine 内部调用——否则可能因竞态导致计数漏加
  • wg.Done() 一定要放在 defer 中,确保无论成功失败都执行
  • 主 goroutine 调用 wg.Wait() 会阻塞,适合命令行工具等简单场景;若需超时控制,改用 sync.WaitGroup 配合 context.WithTimeout
for _, url := range urls {
    wg.Add(1)
    go func(u string) {
        defer wg.Done()
        resp, err := http.Get(u)
        if err != nil {
            log.Printf("fail to fetch %s: %v", u, err)
            return
        }
        defer resp.Body.Close()
        // ... save body
    }(url)
}
wg.Wait()

限制并发数:用带缓冲的 chan struct{} 控制 goroutine 数量

不加限制地为每个 URL 启动 goroutine,容易打爆内存或触发服务端限流。用容量固定的 channel 做信号量是最 Go 风格的限流方式,比 semaphore 包更直观、无额外依赖。

  • channel 容量即最大并发数,例如 make(chan struct{}, 5) 表示最多 5 个下载同时进行
  • 每次启动 goroutine 前写入 sem ,完成后从 channel 读出(),顺序不重要但必须成对
  • 不要用 close(sem)——它会导致后续写入 panic,且无法重用
sem := make(chan struct{}, 5)
for _, url := range urls {
    sem <- struct{}{} // acquire
    go func(u string) {
        defer func() { <-sem }() // release
        // ... download logic
    }(url)
}
// wait for all
for i := 0; i < len(urls); i++ {
    <-sem // drain semaphore
}

下载失败时如何重试与错误归集

HTTP 下载常因网络抖动失败,但盲目重试可能加剧问题。应区分错误类型,并统一收集失败项供后续处理,而不是让单个失败中断整个流程。

  • errors.Is(err, context.DeadlineExceeded) 或检查 url.Error().Error() 是否含 "timeout" 来识别可重试错误
  • 非重试错误(如 404、证书错误)应立即记录并跳过
  • 建议把失败的 url 和错误一起 append 到切片,而不是打印后丢弃——下游可能要重试或告警
var failed []struct{ URL string; Err error }
for _, url := range urls {
    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        if isTemporaryError(err) {
            // retry once with backoff
        } else {
            failed = append(failed, struct{ URL string; Err error }{url, err})
        }
    }
}

文件写入竞争:每个下载任务独立打开文件,别共用 *os.File

多个 goroutine 同时往同一个 *os.File 写内容,即使加锁也容易错乱(seek 位置不可控、write 返回值难校验)。正确做法是每个下载 goroutine 自己调用 os.Createioutil.WriteFile,互不影响。

立即学习“go语言免费学习笔记(深入)”;

  • 避免用 os.OpenFile(..., os.O_WRONLY|os.O_APPEND) 多 goroutine 共享——APPEND 模式不保证原子性,尤其在 NFS 或某些文件系统上
  • 若需按顺序写入单个文件(如拼接分片),改用 io.MultiWriter + 单独 goroutine 接收 channel 数据,主下载 goroutine 只负责获取字节流
  • 临时文件建议用 os.CreateTemp,下载完成再 os.Rename,防止部分写入被误读

并发下载真正麻烦的从来不是“怎么发请求”,而是错误传播路径、资源释放时机、以及写磁盘时的隐式依赖。哪怕只加一行 defer resp.Body.Close() 漏掉,都可能让几千次下载慢慢耗尽文件描述符。