Golang实现支持断点续传的文件同步工具-Golang-PHP中文网

断点续传需自行控制http头、文件打开模式（禁用os.o_append）、seek位置及中断恢复逻辑，必须通过head+range试探验证服务端真实支持能力，并持久化.offset状态至.syncstate文件。

golang实现支持断点续传的文件同步工具

直接用 os.Copy 或简单 io.Copy 配合 http.Get 无法实现可靠断点续传——它既不校验服务端是否真支持 Range，也不处理文件偏移错位、写入覆盖、状态丢失等核心问题。必须自己控制 HTTP 头、文件打开模式、seek 位置和中断恢复逻辑。

光看响应头 Accept-Ranges: bytes 是陷阱：Nginx、CDN 常伪造该字段，但实际对 Range 请求返回 200 OK 或直接 500。必须用试探请求验证行为。

先发一个 HEAD /path/to/file，拿到 Content-Length 和 Accept-Ranges
再发 GET /path/to/file 带 Range: bytes=0-1023，检查响应码是否为 206 Partial Content，且 Content-Range 值匹配（如 bytes 0-1023/12345678）
若返回 200，说明服务端忽略 Range，应清空本地文件走全量下载；若返回 416，说明已知长度不一致，需重新 HEAD 获取真实长度
不要依赖客户端传来的 Upload-Offset 或 Content-Range 字段做唯一判断——它们可能被篡改或计算错误

os.O_APPEND 是断点续传最隐蔽的坑：它会让所有 Write() 调用强制跳转到文件末尾，完全无视你之前调用的 file.Seek(offset, io.SeekStart)。POSIX 行为 + Go 运行时共同导致数据错位或填充空白。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

正确打开方式是：os.OpenFile(filename, os.O_WRONLY|os.O_CREATE, 0644)（不加 O_TRUNC，不加 O_APPEND）
打开后立刻调用 file.Seek(offset, io.SeekStart)，并检查返回值是否等于 offset；不等说明文件已被外部修改，不可信
写入前可选调用 file.Truncate(expectedSize) 清除尾部脏数据，避免稀疏文件问题
并发写同一文件时，Seek+Write 非原子，必须用 sync.Mutex 包裹，或改用单 goroutine 顺序写

本地文件已存在时，“当前长度”不等于“可信续传起点”。崩溃、截断、部分写入都会让 fi.Size() 失效。必须结合偏移校验与轻量哈希。

每次开始续传前，用 os.Stat() 获取当前文件大小作为初始 offset，但仅作参考
写入前调用 file.Seek(offset, io.SeekStart)，失败则中止；成功后建议立即 file.Sync()，防止内核缓存未刷盘影响下次读取
对大文件或高一致性要求场景，客户端应在请求头带 X-Prev-Chunk-Hash: sha256...，服务端读取对应区间比对；不匹配就返回 416 并附带正确 Content-Range
用 io.LimitReader(src, expectedBytes) 包裹响应体，防止客户端谎报长度后发送多余字节

把 offset 存内存或只靠文件长度推断，服务重启、进程崩溃、部署更新后就全丢了。状态必须持久化，且足够轻量。

推荐方案：为每个同步任务生成一个 .syncstate 文件，内容为 JSON：{"filename":"a.zip","offset":1234567,"etag":"abc123","updated":"2026-06-08T23:20:00Z"}
写入时先写临时文件（如 .syncstate.tmp），再 os.Rename() 原子提交，避免写一半崩溃导致状态损坏
不要用数据库或 Redis 存这种元信息——引入额外依赖、网络延迟、连接失败风险，违背工具轻量初衷
每次同步前先读取该文件，校验 filename 和 etag 是否仍匹配（etag 可从服务端 HEAD 响应中获取），不匹配则视为新任务