Golang初级实战：多线程下载器_实现并发下载与进度条显示

应使用 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 收进度，再安全输出。