HTTP客户端默认不支持并发下载控制，因其虽并发安全但缺乏限速、统一超时和连接复用管理，易导致文件描述符耗尽、DNS解析失败或连接瓶颈；需结合信号量、流式IO、Context超时与合理重试机制协同管控。
为什么 http.Client 默认不支持并发下载控制？
Go 的 http.Client 本身是并发安全的，但默认没有内置限速、超时统一管理或连接复用策略——这意味着直接开几百个 go http.Get(...) 很容易打爆本地文件描述符、触发 dial tcp: lookup failed: no such host 或 too many open files 错误。根本问题不在并发能力，而在资源失控。
- 每个
http.Client默认使用http.DefaultTransport，其MaxIdleConns和MaxIdleConnsPerHost默认为 100，远低于常见下载任务需求 - DNS 解析、TLS 握手、TCP 连接建立都可能成为瓶颈，尤其批量下载不同域名时
- 没设
Timeout或Context超时，单个失败请求会拖住整个 goroutine 池
用 semaphore 控制并发数比 chan struct{} 更可靠
很多人用带缓冲的 chan struct{} 做信号量，但容易漏写 defer close() 或误读 channel 状态。标准库虽无原生信号量，但 golang.org/x/sync/semaphore 提供了带权重、可取消、线程安全的实现，更适合下载场景。
- 初始化：
sem := semaphore.NewWeighted(int64(maxConcurrency)) - 获取许可：
if err := sem.Acquire(ctx, 1); err != nil { return }（支持上下文取消） - 释放许可：
defer sem.Release(1)（务必 defer，避免 panic 导致泄漏） - 相比
chan方案，它能精确控制“当前活跃请求数”，且不依赖 channel 关闭逻辑
io.Copy 直接流式写入比 io.ReadAll 更省内存
下载大文件时，若先用 io.ReadAll(resp.Body) 读进内存再写磁盘，不仅吃内存，还增加 GC 压力。真实生产环境必须流式处理。
- 正确做法：
out, _ := os.Create(filename); io.Copy(out, resp.Body); out.Close() - 加进度提示？用
io.TeeReader包裹resp.Body，每次读取都回调更新计数器 - 注意：必须在
io.Copy后调用resp.Body.Close()，否则连接无法复用，MaxIdleConns形同虚设 - 如果需校验 checksum，用
hash.Hash接在io.TeeReader后，不要等全部写完再算
如何让重试 + 超时 + 限流三者不互相干扰？
常见错误是把 time.Sleep 写在重试循环里，导致整个 goroutine 阻塞；或用全局 time.AfterFunc 管理超时，结果多个请求共享一个 timer。关键在于每个请求独占自己的 context.Context。
立即学习“go语言免费学习笔记（深入）”；
- 每次发起请求前：
reqCtx, cancel := context.WithTimeout(ctx, perRequestTimeout) - 重试逻辑放在 for 循环内，每次重试都新建 request，并用新
reqCtx传入http.NewRequestWithContext - 限流许可（
sem.Acquire）应在重试循环外获取一次，避免每次重试都抢锁——失败重试不该再消耗并发额度 - 最终 cancel 必须调用，哪怕请求成功，否则 context 泄漏
