如何用Golang实现并发下载器_Golang并发下载项目实战

应全局复用 http.Client 并配置 Transport 连接池参数，用 semaphore 控制并发，io.copy 替代手动读写，结合指数退避重试与错误分类，以避免 fd 耗尽、goroutine 泛滥和边界处理缺陷。

为什么 http.Client 要自定义并复用，而不是每次新建？

并发下载时如果每个 goroutine 都新建一个 http.Client，会快速耗尽本地文件描述符（报错类似 dial tcp: lookup xxx: no such host 或 too many open files），因为默认的 http.Transport 没有限制连接池大小，且 dns 缓存、TLS 会话复用等机制全失效。

实操建议：

• 全局复用一个 http.Client，设置 Transport.MaxIdleConns 和 Transport.MaxIdleConnsPerHost（例如都设为 100）
• 启用 Transport.IdleConnTimeout（如 30s）防止长连接堆积
• 若需带鉴权或特殊 Header，不要改全局 Client，而是用 context.WithValue 传参，或为不同任务建专用 client 实例（但仍是复用 transport）

如何安全地控制并发数，避免 goroutine 泛滥？

用 semaphore（信号量）比简单起一堆 goroutine 更可靠。Go 标准库没内置，但可用带缓冲的 channel 模拟，或引入 golang.org/x/sync/semaphore。

常见错误：用 runtime.GOMAXPROCS 控制并发 —— 它只影响 OS 线程调度，和你的下载 goroutine 数量无关。

立即学习“go语言免费学习笔记（深入）”；

实操建议：

• 初始化一个 semaphore.Weighted，容量设为期望最大并发数（如 5）
• 每个下载任务前调用 sem.Acquire(ctx, 1)，完成后 sem.Release(1)
• 务必在 defer 中 release，否则一旦 panic 或 return 早于 release，信号量就泄漏
• 注意：Acquire 可能阻塞，所以要传带超时的 ctx，避免某个卡死任务拖垮整个下载队列

io.Copy 直接写文件为啥比自己循环 Read/Write 更稳？

手动读写容易漏处理部分写（Write 返回字节数可能小于 len(buf)）、忽略 io.EOF 边界、忘记 flush，而 io.Copy 内部已处理所有这些边界情况，并自动使用最优 buffer 大小（默认 32KB）。

实操建议：

• 用 io.Copy(dst, resp.Body)，dst 是 *os.File，别用 os.Stdout 测试完就上线
• 如果需要进度回调，用 io.TeeReader 包裹 resp.Body，再传给 io.Copy
• 别在 Copy 过程中对文件做 Seek 或 Truncate —— 不安全，除非你明确加了 sync.Mutex
• 下载中断后想续传？那得换 Range 请求 + os.OpenFile(..., os.O_appEND)，此时不能再用 io.Copy 原样写，得自己管理 offset

下载失败时怎么重试又不卡住整个队列？

直接 for-loop 重试会阻塞当前 goroutine，且无法统一退避（backoff）。更糟的是，如果所有请求同时失败又立刻重试，可能触发服务端限流。

实操建议：

• 用指数退避：第一次 100ms，第二次 200ms，第三次 400ms……上限设为 2s 即可
• 每次重试前检查 ctx.Err()，避免在取消后还傻等
• 失败日志里必须包含 URL、状态码、错误类型（net.Error？url.Error？）、重试次数，否则线上排查抓瞎
• 对 404、403 这类客户端错误，重试无意义，应直接标记失败；5xx 才值得重试

并发下载真正的复杂点不在“怎么开 goroutine”，而在连接复用、资源节制、错误分类与可观测性——这些地方一松懈，程序跑两天就内存暴涨或 fd 耗尽。