Golang文件下载中断如何续传_Golang断点续传思路解析

能续传需服务端支持断点续传，即 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，可能就丢了半张表。