能续传需服务端支持断点续传，即 HTTP 响应头含 Accept-Ranges: bytes；客户端须先 HEAD 校验该字段及 Content-Length，并用 Seek+CopyN 精准写入分块，配合元数据文件记录各 chunk 状态及 ETag 实现可靠恢复与并发控制。
怎么判断能不能续传？先看服务端支不支持
断点续传不是客户端单方面能决定的，关键看服务端是否返回 Accept-Ranges: bytes。不支持的话，Range 请求会被忽略，响应还是 200 OK 全量内容，甚至直接 416 错误。所以第一步永远是 http.Head()：
- 检查
resp.StatusCode == http.StatusOK（有些 CDN 或反向代理对 HEAD 返回 405，可 fallback 到 GET + 关闭 body） - 读取
resp.Header.Get("Accept-Ranges")，必须严格等于"bytes"，不能是"none"或空字符串 - 同时拿到
Content-Length，这是后续分块和校验的基准值
常见坑：本地文件存在但服务端已更新（比如同 URL 重传了新版本），此时 Content-Length 变了，继续用旧 offset 续传会导致文件损坏。稳妥做法是每次下载前都重新 HEAD 校验大小是否一致。
续传时文件怎么写？别用 O_APPEND 就完事
O_APPEND 看似简单，但它只保证“写入位置在当前文件末尾”，而多线程分块下载时，每个 goroutine 需要精准写到 [start, end] 区间——这必须靠 file.Seek(start, 0) + io.CopyN 实现。否则会覆盖、错位或写乱序。
- 单线程续传可用
O_WRONLY | O_CREATE | O_APPEND，但仅限从末尾追加；一旦中间断掉（比如写到 80% 时 panic），下次还得从头算 offset，不如统一用Seek - 多线程场景下，
os.OpenFile(..., os.O_WRONLY)后立刻file.Seek(start, 0)，再io.CopyN(dst, src, chunkSize)，避免因写入缓冲或调度导致偏移错位 - 务必用
io.CopyN而非io.Copy：防止服务端响应体超出预期长度（比如 CDN 注入 HTML 错误页），造成越界写入
中断后怎么恢复？状态不能只靠文件大小猜
很多人以为 “读本地文件长度，然后 Range: bytes=N-” 就够了，但磁盘缓存、写入未刷盘、部分 chunk 写失败等情况会让文件长度“虚高”。真正可靠的恢复，得靠显式记录每个分块的完成状态。
立即学习“go语言免费学习笔记（深入）”；
- 维护一个 JSON 元数据文件（如
file.zip.part.meta），字段至少包含：url、size、chunks数组（每项含start、end、done） - 每个 chunk 下载成功后，原子更新 meta 文件：先写临时文件
.meta.tmp，再os.Rename替换，避免写一半崩溃导致元数据损坏 - 启动时优先加载 meta；若 meta 不存在或解析失败，清空临时文件并重新开始，而不是冒险续传
容易被忽略的是：meta 文件里还该存 ETag 或 Last-Modified，下次下载前比对，发现服务端资源已变就强制清空重下，不然续传的可能是两个不同文件的拼接体。
并发分块下载时，怎么避免写冲突和超时雪崩？
开 10 个 goroutine 同时请求，看似快了，但没控制反而更慢：连接池耗尽、服务端限流、本地 fd 不够、DNS 查询阻塞……
- 用带缓冲的 channel 或
semaphore控制最大并发数（建议默认 3–5），例如make(chan struct{}, 4)，每个 goroutine 先ch 再干活，结束时 -
http.Client必须自定义Transport：设置MaxIdleConnsPerHost（建议 ≥ 并发数）、IdleConnTimeout（30s）、TLSHandshakeTimeout（10s） - 每个分块请求单独设超时：
context.WithTimeout(ctx, 60*time.Second)，避免一个卡死拖垮全部；失败 chunk 记录到 meta 中，后续可单独重试
真正难的不是并发本身，而是让并发变得“可中断、可恢复、可诊断”——所有网络操作都要有 context 取消，所有写入都要有原子落盘，所有状态都要可序列化。否则一次 Ctrl+C，可能就丢了半张表。
