go 的 net/http 不支持断点续传或多段并发下载，需手动实现：先 HEAD 获取 Content-Length，再按并发数均分 Range；用 WriteAt 预分配文件空间后并发写入；通过带缓冲 channel 控制 goroutine 数量。
Go 的 net/http 本身不支持断点续传或多段并发下载，必须自己拆分 Range、管理连接、合并文件——这不是加几个 go 关键字就能跑起来的事。
如何正确拆分 HTTP Range 请求
直接按字节均分容易出错：服务端可能不支持 Range（返回 200 而非 206），或实际文件大小在请求过程中变化。必须先发一次 HEAD 获取 Content-Length，再根据目标并发数（如 4）计算每段起始偏移：
- 用
http.Head()拿到Content-Length，若返回非 200 或无该 header，降级为单线程下载 - 每段长度 =
totalSize / goroutineCount，最后一段包含余数；避免某段为 0 字节 - 每个
http.Request必须显式设置Header.Set("Range", "bytes=0-1048575")，且检查响应状态码是否为206 Partial Content
为什么不能直接用 io.copy 写入同一文件句柄
多个 goroutine 并发写同一个 *os.File 会导致数据错乱——WriteAt 才是安全的，但前提是文件已预分配空间（否则写入时扩展文件会引发竞态）：
- 先用
os.Truncate()或os.WriteAt()配合bytes.Repeat([]byte{0}, totalSize)初始化空文件 - 每个 goroutine 拿到自己的
start偏移后，用file.WriteAt(buf, int64(start))写入，不依赖当前文件偏移 - 切忌用
file.Seek()+file.Write()，Seek 是共享状态，无法保证原子性
如何控制并发数并处理失败重试
盲目启动 100 个 goroutine 不仅不会提速，反而触发服务端限流或本地 fd 耗尽。要用带缓冲的 channel 控制活跃 worker 数量：
立即学习“go语言免费学习笔记（深入）”；
- 定义
sem := make(chan Struct{}, 4)，每个下载 goroutine 启动前sem ，结束时 - 单段下载失败（如网络超时、503）应指数退避重试，但最多 3 次；超过则标记该段失败，最后汇总错误
- 所有 goroutine 完成后，需检查每段是否都写入成功（可比对
Content-Range响应头与预期字节数），缺失段要单独补下
真实场景中容易被忽略的细节
很多教程漏掉这些，结果在生产环境跑半天才发现问题：
- HTTP/2 连接复用会让多个
Range请求串行化，强制用&http.Transport{ForceAttemptHTTP2: false}切回 HTTP/1.1 - 某些 CDN（如 Cloudflare）对高频 Range 请求返回 429，得加随机 delay（如
time.Sleep(time.Millisecond * time.Duration(rand.Intn(100)))） - 下载大文件时，
response.Body必须用io.LimitReader包裹，防止恶意服务端返回远超Content-Range声明的字节导致内存爆满