HTTP分片下载需手动设Range头，因客户端须主动声明请求范围，服务端是否响应206并正确返回Content-Range取决于自身支持；io.Copy不参与协议协商，无法自动处理。
为什么 http.Range 头必须手动设置，而不是靠 io.Copy 自动处理
因为 http 分片下载本质是客户端主动声明“我只要哪一段”，服务器是否支持、返回多少数据，完全取决于服务端是否响应 206 partial content 并正确设置 content-range。go 的 http.client 不会自动加 range 头——它默认发的是完整请求（get），哪怕你只读前 1mb，服务端仍可能返回整个 10gb 文件。
实操要点：
- 每次发起请求前，必须显式设置
req.Header.Set("Range", "bytes=1048576-2097151") - 务必检查响应状态码：不是
206就说明服务端不支持分片，不能继续分片逻辑 -
Content-Length在206响应里表示当前分片大小，不是原文件总长；总长得从Content-Range头里解析，例如bytes 1048576-2097151/10737418240→ 总长10737418240
如何安全地并发写入同一个文件的多个分片
不能用 os.O_APPEND：它只保证“追加原子性”，但多个 goroutine 同时 Write 会导致内容错位或覆盖。正确做法是每个分片单独打开文件（os.O_WRONLY），用 file.Seek(offset, 0) 定位，再写入。
关键细节：
- 文件必须提前创建并预分配大小（
os.Truncate），否则写入末尾会触发扩容，引发竞争 - 每个分片 goroutine 独立打开文件（
os.OpenFile(..., os.O_WRONLY, 0)），避免共享*os.File实例 - 写入前调用
file.Seek(start, 0)，确保写入位置精准；写完不关闭文件句柄（系统限制），用defer file.Close()或统一管理 - 建议加简单重试（如失败后 sleep 1s 再试 2 次），网络抖动时比直接 panic 更健壮
context.WithTimeout 必须包住整个分片请求，而不是只包 http.Do
单个分片下载卡住（比如服务端迟迟不发响应体）时，仅给 http.Do 设超时没用——如果连接已建立、响应头已收到（206），但响应体流速极慢，http.Client.Timeout 不会触发，goroutine 会永久阻塞在 io.Copy 上。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
正确姿势：
- 为每个分片启动独立 goroutine，并传入带超时的
ctx：ctx, cancel := context.WithTimeout(parentCtx, 30*time.Second) - 在 goroutine 内部，用
ctx构造新http.Request（req = req.WithContext(ctx)） - 把
io.Copy也放在select+ctx.Done()监控下，或者用io.CopyN配合定时器 - 注意：超时后要调用
cancel()，否则可能泄漏 goroutine
校验和怎么加才不影响并发性能又不丢精度
边下载边计算 SHA256 会拖慢写入速度，但等全部写完再算又无法及时发现传输损坏。折中方案是：每个分片写入内存 buffer 后立即计算该段哈希，存到 map 中；所有分片完成后，用 sha256.New() 按顺序 Write 各段 hash（不是原始数据），最后再 Sum —— 这叫 Merkle-style 校验，能并行且结果等价于全量计算。
更实用的做法（推荐）：
- 每个分片 goroutine 写文件前，先用
hash.Hash.Write(buf)计算本段 SHA256，把结果存进[][32]byte切片（索引即分片序号） - 全部完成后再起一个 goroutine，按顺序把各段 hash 拼起来，再算一次顶层 hash（可选）
- 如果要求强一致性，下载完立刻用
os.Open重新读取全文件做最终校验——但这一步必须串行，且大文件会很慢，建议仅用于关键场景
真正容易被忽略的是：HTTP 分片下载没有标准断点续传协议，Content-Range 头不可信，服务端可能静默返回错误范围（比如请求 1MB–2MB，却返回了 0–512KB）。必须校验每次写入的字节数是否等于预期长度，否则后续所有哈希和拼接都白做。
