答案：因默认MaxIdleConnsPerHost=2导致连接池瓶颈，goroutine阻塞超时，并发过高引发文件描述符和DNS耗尽；须协同配置MaxIdleConns、MaxIdleConnsPerHost≥并发数及IdleConnTimeout，用私有client与信号量控制并发。
并发下载多个文件时，为什么直接起 goroutine 会失败
因为 http.DefaultClient 的连接池默认只允许每 host 最多 2 个空闲连接（MaxIdleConnsPerHost = 2），10 个 goroutine 同时发请求，8 个会卡在连接获取阶段，超时或阻塞；同时系统级文件描述符（too many open files）和 DNS 查询（lookup xxx: no such host）也会快速耗尽。
常见错误现象：dial tcp: lookup example.com: no such host、context deadline exceeded、too many open files，不是代码逻辑错，是资源没管住。
- 必须显式配置
http.Transport：把MaxIdleConns和MaxIdleConnsPerHost设为 ≥ 并发数（如 20），并设IdleConnTimeout防止连接堆积 - 不要复用全局
http.Client做不同超时策略的任务；下载任务统一用私有 client，带Timeout和Transport - 并发数别硬写死成 100；5–10 是更安全的起点，视目标服务器容忍度调整
用 semaphore 控制并发数比 channel 更稳
用 make(chan struct{}, N) 做信号量容易漏掉 导致后续 goroutine 永久阻塞——这是线上最常踩的坑。而 <code>golang.org/x/sync/semaphore 的 Acquire/Release 是原子且可 cancel 的，出错也能释放。
实操要点：
立即学习“go语言免费学习笔记（深入）”；
- 必须在 goroutine 内部调用
sem.Acquire(ctx, 1)，不能在 for 循环里提前 acquire，否则主线程被卡 -
defer sem.Release(1)要紧贴 goroutine 函数体开头，确保无论成功失败都释放 - 别用
time.Sleep模拟限流——它不释放连接、不控制资源，只是让错误延迟暴露
进度回调不能靠 io.Copy，得自己包一层 Reader
io.Copy 内部调用 Read 但不暴露字节数，进度条要么不动要么跳变。必须实现一个带计数的 io.Reader，在每次 Read 后累加并触发回调。
关键细节：
- 回调函数别直接刷新终端或发 HTTP 请求——
Read可能每 KB 触发一次，高频 IO 会拖慢整个下载；建议用sync/atomic累加，另起 goroutine 每 100ms 聚合上报一次 - 多个 goroutine 写同一个进度变量时，必须用
atomic.AddInt64，别用mutex锁整个更新逻辑，否则变成串行瓶颈 - 别在
Read里做耗时操作（如格式化字符串、日志打印），只做原子计数
单个大文件分块下载，WriteAt 才安全
多个 goroutine 对同一 *os.File 调 Write 或 Seek + Write 会因共享偏移量导致数据错乱。唯一安全方式是预分配文件空间后，每个 goroutine 独立调 WriteAt(buf, offset)。
注意点：
- 打开文件时用
os.O_WRONLY | os.O_CREATE，**禁用os.O_TRUNC**，否则其他协程正在写时被清空 - 必须先用
os.Truncate或file.WriteAt初始化全文件为零（如bytes.Repeat([]byte{0}, totalSize)），否则WriteAt在未初始化区域写入可能失败 - 服务端不返回
Accept-Ranges: bytes时，别强行分块——用curl -I -H "Range: bytes=0-1023" URL预检，失败就降级为单 goroutine 流式下载
