Go并发下载需限制goroutine数量并配置http.Client：设MaxIdleConns/PerHost、用channel控并发、每任务独立context.WithTimeout、写文件须隔离路径或加锁，优先用io.Copy确保健壮性。
Go 语言本身没有“多线程下载”这个概念，它用 goroutine + channel 实现并发下载，比传统多线程更轻量、更易控——但直接开几百个 goroutine 不加限制，反而会压垮服务器或触发限流。
goroutine 数量必须限制，否则 http.Client 会超时或被拒绝
不设限地启动 goroutine 下载，常见现象是：前几秒很快，随后大量 context deadline exceeded 或 connection refused。这是因为：
-
http.DefaultClient的底层net/http.Transport默认只允许最多 100 个空闲连接（MaxIdleConns），且对单域名默认仅 2 个（MaxIdleConnsPerHost） - 操作系统级文件描述符/端口耗尽，尤其在 Linux 上容易触发
too many open files - 目标服务器主动限流（如返回 429 或直接断连）
实操建议：
显式配置 http.Client，并用带缓冲的 channel 控制并发数：
立即学习“go语言免费学习笔记（深入）”；
client := &http.Client{
Transport: &http.Transport{
MaxIdleConns: 200,
MaxIdleConnsPerHost: 200,
IdleConnTimeout: 30 * time.Second,
},
}
sem := make(chan struct{}, 10) // 并发上限设为 10，稳妥起见每个下载任务需独立 context.Context，避免一个失败拖垮全部
如果所有 goroutine 共享同一个 context.WithTimeout，某个慢请求超时后，整个 context 被 cancel，其余还在跑的下载也会立即中断——这不是你想要的“并发”，而是“共死”。
正确做法是：每个下载任务生成自己的子 context，并设置独立超时（比如 30 秒）：
go func(url string) {
sem <- struct{}{} // 获取信号量
defer func() { <-sem }() // 归还
<pre class="brush:php;toolbar:false;">ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
resp, err := client.Do(req)
// ... 处理 resp / err}(url)
注意：context.WithTimeout 必须在 goroutine 内部调用，不能在外层统一传入——否则所有任务共享同一 deadline。
写文件必须加锁或隔离路径，否则多个 goroutine 写同一个 *os.File 会乱序/覆盖
常见错误：开 10 个 goroutine 同时向 output.bin 写数据，结果文件内容错乱、大小不对、甚至 panic 报 write on closed file。
解决方式取决于需求：
- 若下载的是不同 URL → 每个任务写独立文件（推荐）：
os.Create(fmt.Sprintf("dl_%d.bin", i)) - 若需合并成一个文件（如分块下载）→ 必须用
sync.Mutex包裹file.Write()，或改用io.WriteString+ 偏移写入（需提前file.Seek()） - 避免用
os.Stdout或未同步的全局*os.File直接写
实际项目中，优先用 io.Copy 而非手动 io.Read/io.Write
手动循环读写不仅代码冗长，还容易漏掉错误检查、忽略 partial write、忘记 resp.Body.Close()，导致连接无法复用。
简洁安全的做法：
resp, err := client.Do(req)
if err != nil { return }
defer resp.Body.Close()
<p>out, err := os.Create(filename)
if err != nil { return }
defer out.Close()</p><p>_, err = io.Copy(out, resp.Body) // 自动处理流式拷贝、buffer、错误传播
如果需要进度反馈，再包装一层 io.TeeReader 或用 io.MultiWriter 配合计数器——但别为了“显示进度”牺牲健壮性。
真正难的不是并发本身，而是控制资源水位、隔离失败影响、以及理解 HTTP 连接复用和文件系统约束。很多“下载慢”或“崩了”的问题，根源不在 goroutine，而在 http.Transport 配置或文件打开方式。
