根本原因是默认 HTTP 客户端连接池限制：MaxIdleConnsPerHost 默认为2，导致同一域名请求排队；需调大该值并用独立http.Client，分片下载+Range头避免并发写冲突，配合context超时防卡死。
为什么 go 启动的 goroutine 无法并发下载文件？
常见现象是：写了多个 go downloadFile(url, dst)，但实际下载速度没提升，甚至变慢。根本原因不是 goroutine 没起作用，而是默认的 HTTP 客户端复用底层 TCP 连接池（http.DefaultTransport），而它的 MaxIdleConnsPerHost 默认值是 2 —— 意味着同一域名最多只保持 2 个空闲连接，后续请求排队等待。
- 把
http.DefaultTransport的MaxIdleConnsPerHost设为足够大的数（如 100） - 显式创建独立的
http.Client，避免被其他逻辑意外修改全局 transport - 注意：不是越大越好，超过目标服务器承受能力反而触发限流或拒绝连接
如何安全地并发写入同一个文件？
多个 goroutine 直接 f.Write() 同一个 *os.File 会导致数据错乱或 panic —— 文件描述符是共享资源，Write() 不是原子操作。正确做法是按分片下载、再合并，或用同步机制隔离写入。
- 推荐分片下载：用
Range请求头指定字节区间（如"bytes=0-1048575"），每个 goroutine 下载一段，最后用os.OpenFile(..., os.O_WRONLY|os.O_CREATE, 0644)随机写入对应位置 - 若必须顺序追加（如日志类场景），用
sync.Mutex包裹f.Write()，但会严重削弱并发收益 - 切勿用
fmt.Fprintln(f, ...)并发写，它隐含格式化+换行，竞争更隐蔽
io.Copy 在并发场景下为什么容易卡住？
io.Copy(dst, src) 是阻塞调用，如果某个下载链接响应极慢或挂起，对应 goroutine 就一直卡在那儿，既不超时也不释放资源，拖垮整个下载队列。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须给每个请求设置
context.WithTimeout，并传入http.Request.WithContext() - 不要依赖
http.Client.Timeout全局设置 —— 它只控制连接建立和首字节读取，不涵盖整个 body 传输过程 - 用
io.CopyN或带缓冲的io.Copy+select配合time.After实现更精细的传输超时（例如每 5 秒检查一次进度）
如何判断并发下载是否真的生效？
光看 CPU 或 goroutine 数量没意义。真正指标是网络吞吐（bytes/sec）和总耗时下降。常见假象包括：DNS 解析阻塞、目标服务器限速、本地磁盘 I/O 成瓶颈。
立即学习“go语言免费学习笔记（深入）”；
- 用
curl -w "@format.txt" -o /dev/null URL单独测单个链接的time_connect和speed_download，确认服务端无限制 - 启动下载前用
netstat -an | grep :443 | wc -l观察 ESTABLISHED 连接数是否随 goroutine 增多而上升 - 写入阶段加
runtime.ReadMemStats对比前后Alloc，突增说明频繁分配小 buffer（比如每次make([]byte, 4096)而没复用sync.Pool）
