Golang多线程下载器实现与进度条

本文深入探讨了如何在 Go 语言中构建一个高效、稳定的多线程下载器，重点强调并发控制的实践智慧：避免盲目启动大量 goroutine 导致文件描述符耗尽或触发 HTTP 限流，而是通过 sync.WaitGroup 与带缓冲的限流 channel（如 sem := make(chan struct{}, 10)）协同实现精准的并发数管理，既保障下载性能，又确保系统资源安全与服务稳定性——这不仅是技术选型，更是工程落地的关键分寸。

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 ，结束时 <-sem
• WaitGroup 只负责“等所有任务结束”，不参与限流

漏掉 <-sem 会导致 channel 堵死，后续下载永远卡住——这是最常被忽略的 defer 缺失点。

进度条显示依赖 io.MultiWriter + 实时回调，不是等下载完再算

进度条要动，就得在下载过程中持续拿到已读字节数。用 http.Get 拿到 resp.Body 后，不能直接 io.Copy 到文件，得套一层可观察的 reader。

推荐组合：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 收进度，再安全输出。

好了，本文到此结束，带大家了解了《Golang多线程下载器实现与进度条》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！