Go并发下载需控制goroutine数量、复用HTTP连接、分块处理响应体；建议5–20并发，用信号量或带缓冲channel限流，避免耗尽文件描述符或触发服务端限流（如429）。
用 Go 实现并发下载文件，核心是合理控制 goroutine 数量、复用 HTTP 连接、分块处理响应体，避免盲目开大量协程导致连接耗尽或服务端限流。关键不在“越多越快”，而在“稳且准”。
控制并发数，避免压垮客户端和服务端
无限制启动 goroutine 会快速占满本地文件描述符、触发 TCP TIME_WAIT 堆积，也可能被目标服务器拒绝（如返回 429 或直接断连）。建议根据网络环境和目标服务策略设置合理上限，通常 5–20 个并发较稳妥。
- 用 semaphore（信号量） 或带缓冲的 channel 控制活跃 goroutine 数量
- 例如：
sem := make(chan struct{}, 10)，每个下载前sem ，完成后 - 配合 context.WithTimeout 防止单个请求无限阻塞
复用 HTTP 连接，减少握手开销
默认 http.Client 每次请求都可能新建 TCP 连接，尤其 HTTPS 下 TLS 握手成本高。启用连接池能显著提升吞吐。
- 配置 http.Transport：设置
MaxIdleConns、MaxIdleConnsPerHost（建议 ≥ 并发数）、IdleConnTimeout（如 30s） - 禁用压缩（
DisableKeepAlives: false，保持默认即可） - 避免每次下载都 new Client，全局复用一个配置好的 *http.Client
流式写入 + 分块读取，降低内存压力
大文件不建议一次性 io.ReadAll，易 OOM；也不建议用 os.Create 后反复 Write 小块——系统调用过多。应结合 bufio.Writer 和固定 buffer 流式处理。
立即学习“go语言免费学习笔记（深入）”；
- 用
resp.Body直接读，搭配make([]byte, 32*1024)缓冲区 - 写入时用
bufio.NewWriterSize(f, 64*1024)，最后别忘Flush() - 可选：加进度回调，每读完 N KB 触发一次通知（适合 CLI 工具）
错误重试 + 状态码判断，增强健壮性
网络波动、临时 5xx、302 重定向失败都会中断下载。简单重试 + 判断状态码能覆盖多数异常场景。
- 对 429、500、502、503、504 等状态码做指数退避重试（最多 3 次）
- 检查
resp.StatusCode，非 2xx/3xx 时不要直接写文件 - 对重定向（3xx），确保
Client.CheckRedirect未设为 nil（默认允许） - 注意：不要对 404、403 等客户端错误重试
不复杂但容易忽略。真正提升带宽利用率的，不是并发数堆得多，而是让每个连接跑得稳、传得满、错得少。
