应全局复用 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 耗尽。
