http.Get 直接并发会压垮服务或触发限流，因默认连接池参数偏低、缺乏并发控制及大文件下载内存优化。需配置 Transport 参数、用信号量限流、缓冲写入、分层重试与断点续传。
为什么 http.Get 直接并发会压垮服务或触发限流
多个 goroutine 同时调用 http.Get 发起下载请求，若不加控制，极易触发目标服务器的连接数限制、频率限流（如 429），甚至本地文件描述符耗尽（too many open files）。Go 默认的 http.DefaultClient 底层复用 http.Transport，但其 MaxIdleConns 和 MaxIdleConnsPerHost 默认值偏低（均为 100），在高并发下载场景下成为瓶颈。
实操建议：
- 显式配置
http.Transport：将MaxIdleConns和MaxIdleConnsPerHost设为合理上限（如 200–500），并设置IdleConnTimeout避免连接长期空闲 - 避免复用全局
http.Client时混用不同超时策略；下载任务建议统一用带Timeout的私有 client - 对同一域名大量请求，需注意
MaxConnsPerHost（Go 1.19+ 支持）防止单 host 连接打满
用 semaphore 控制并发数比 runtime.GOMAXPROCS 更可靠
runtime.GOMAXPROCS 控制的是 OS 线程调度粒度，和实际 HTTP 并发请求数无关。真正需要限制的是同时活跃的下载 goroutine 数量，否则内存和 socket 资源会指数级增长。
推荐用轻量信号量（如 golang.org/x/sync/semaphore）而非 channel 模拟计数器：
立即学习“go语言免费学习笔记（深入）”；
var sem = semaphore.NewWeighted(5) // 最多 5 个并发
for _, url := range urls {
url := url // 防止循环变量捕获
go func() {
if err := sem.Acquire(context.Background(), 1); err != nil {
log.Printf("acquire failed: %v", err)
return
}
defer sem.Release(1)
downloadFile(url)
}()
}
注意点：
- 必须在 goroutine 内部调用
Acquire，否则阻塞主线程 - 务必
defer sem.Release(1)，且确保无论成功失败都释放，否则信号量泄漏 - 不要用
time.Sleep替代信号量——它不解决资源竞争，只掩盖问题
下载大文件时别让 io.Copy 吃光内存
直接 io.Copy(dst, resp.Body) 对超大文件（如 >500MB）可能引发 GC 压力陡增或 OOM，尤其当 dst 是 *os.File 且未设置缓冲时，底层会频繁分配小块内存。
优化方式：
- 用带缓冲的
bufio.Writer包裹文件写入器：io.Copy(bufio.NewWriter(f), resp.Body) - 对极敏感场景，改用分块读写：
io.CopyBuffer+ 自定义 1MB 缓冲区（make([]byte, 1） - 务必在
resp.Body.Close()前完成全部读取，否则连接无法复用；可配合io.LimitReader防止恶意超长响应
任务失败重试不能只靠 for 循环
简单 for + sleep 重试会导致所有失败任务同步等待，拖慢整体进度，且无法区分临时错误（如网络抖动）和永久错误（如 404、403）。
应分层处理：
- 对 408/429/5xx 响应码做指数退避重试（用
backoff.Retry或手动实现），最多 3 次 - 对 400/401/403/404 立即失败，记录日志并跳过
- 超时错误（
context.DeadlineExceeded）需检查是否是 client timeout 设置过短，而非盲目重试 - 重试逻辑必须绑定到单个任务 goroutine 内，不可由主协程统一调度
真正难处理的是部分写入后网络中断——此时文件已存在但损坏。生产环境建议下载前先 os.Stat 检查本地文件，再用 Range 请求断点续传（需服务端支持），或下载到临时文件 + os.Rename 原子替换。
