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.Create 或 ioutil.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() 漏掉，都可能让几千次下载慢慢耗尽文件描述符。