应使用 sync.waitgroup 配合限流 channel 控制并发，如 sem := make(chan struct{}, 10)，避免无节制启动 goroutine 导致文件描述符耗尽或 http 限流。
Go 里用 sync.WaitGroup 控制并发下载，别直接开 100 个 goroutine
并发不等于无节制起 goroutine。没限制地调 go downloadFile(url)，几秒内就可能耗尽文件描述符或触发 HTTP 限流，报错 dial tcp: lookup xxx: no such host 或 too many open files。
正确做法是用 sync.WaitGroup 配合固定数量的 worker：
- 先初始化
sem := make(chan struct{}, 10)（控制最多 10 个并发） - 每个下载任务开始前写
sem ，结束时 <code> -
WaitGroup只负责“等所有任务结束”，不参与限流
漏掉 会导致 channel 堵死，后续下载永远卡住——这是最常被忽略的 defer 缺失点。
进度条显示依赖 io.MultiWriter + 实时回调，不是等下载完再算
进度条要动，就得在下载过程中持续拿到已读字节数。用 http.Get 拿到 resp.Body 后，不能直接 io.Copy 到文件，得套一层可观察的 reader。
立即学习“go语言免费学习笔记（深入）”；
推荐组合：io.TeeReader 把流同时送给文件写入器和计数器：
count := int64(0) reader := io.TeeReader(resp.Body, &count) _, err := io.Copy(file, reader)
但注意：count 是全局变量，多 goroutine 写它会竞态。必须用 atomic.AddInt64(&count, n) 或加锁；更稳妥的是把进度回调做成函数参数，每个 worker 自己调自己的 onProgress(int64)。
HTTP 下载中断重试要检查 resp.StatusCode 和 resp.Header.Get("Content-Length")
网络抖动时 http.Get 可能返回 200 但 body 为空，或返回 503 却没进 error 分支（因为连接成功了）。只看 err == nil 不够。
- 必须检查
resp.StatusCode == 200 - 对比
Content-Length和实际写入字节数，差太多说明传输截断 - 重试逻辑别放 for 循环里硬等，用
time.AfterFunc或简单time.Sleep加退避（比如第一次等 1s，第二次 2s）
漏检 Content-Length 会导致“看似下载完成，打开却是损坏文件”，尤其大文件。
终端进度条刷新要用 \r 覆盖行，别用 \n 滚屏
每秒打印一行“Downloaded 12.4 MB / 102.8 MB (12%)”会让日志刷屏，用户根本看不到实时变化。真正有效的进度条是同一行反复覆盖。
关键就一个：输出末尾用 \r，不是 \n，且确保整行长度一致（不够补空格）：
fmt.Printf("\rDownloaded %s / %s (%.1f%%) ",
humanize.Bytes(uint64(downloaded)),
humanize.Bytes(uint64(total)),
float64(downloaded)/float64(total)*100)注意最后三个空格——用来擦掉上一次更长的旧文本；如果用 fmt.Print 而非 fmt.Printf，\r 在 Windows 终端可能失效；Mac/Linux 下基本没问题。
另外，别在 goroutine 里直接 fmt 打印进度——多个 goroutine 竞争 stdout 会导致文字错乱。统一由一个 monitor goroutine 从 channel 收进度，再安全输出。
