如何在Golang中实现断点续传_Seek方法与文件指针

Seek只是移动文件指针，不实现断点续传；断点续传需应用层自行记录进度、校验完整性、配合http Range请求、确保读写位置对齐，并避免多goroutine共用文件句柄。

Go 里 Seek 不是“断点续传”的开关，只是移动文件指针

很多人以为调用一次 Seek 就自动支持断点续传了，其实不是。Seek 只负责把文件读写位置挪到指定偏移量，它不记录进度、不校验完整性、也不管网络是否中断。断点续传是应用层逻辑：你得自己存上次传到哪了，下次从那里接着读+发。

• Seek 的返回值是新的偏移量，必须检查是否等于预期值，否则可能跳错位置
• 对普通文件用 os.O_RDWR 打开才能读写都 Seek；只读打开（os.O_RDONLY）也能 Seek，但后续 Write 会失败
• HTTP 断点续传依赖服务端支持 Range 请求头，客户端光本地 Seek 没用——得配合 req.Header.Set("Range", "bytes=1024-")

用 os.File.Seek 跳到指定位置继续读文件

这是最常见场景：比如上次上传卡在 123456 字节，重启后要从那里继续读。关键不是 Seek 多炫，而是怎么确保“读的位置”和“发出去的字节”严格对齐。

• 用 io.copyN 或手动 Read 配合 Seek，避免用 io.Copy 直接从头拷贝——它会忽略已设的偏移
• file.Seek(123456, io.SeekStart) 是安全的，但 file.Seek(-100, io.SeekCurrent) 容易越界，得先 Stat() 拿总大小做校验
• 注意：windows 下某些 FAT32 分区对大文件 Seek 有精度问题，建议统一用 int64 偏移量，别用 int

offset := int64(123456) _, err := file.Seek(offset, io.SeekStart) if err != nil {     log.Fatal(err) // 比如 offset 超过文件长度会返回 io.EOF }

http.Client 发起 Range 请求时，Seek 和响应 Body 无关

有人试图对 resp.Body 调 Seek，这是错的——http.Response.Body 是个 io.ReadCloser，底层可能是管道或内存 buffer，不支持 Seek。断点续传的“续”，必须发生在请求发起前。

• 构造请求时，用 req.Header.Set("Range", fmt.Sprintf("bytes=%d-", offset))
• 服务端返回状态码是 206 Partial Content，不是 200 OK；如果返回 200，说明服务端不支持 Range，得重下整文件
• 收到响应后，直接从 resp.Body 读，不用 Seek——它已经是你要的那一段了

并发上传分片时，Seek 容易被多个 goroutine 搞乱

一个文件切成 10 个分片，每个 goroutine 自己打开文件、Seek、读一段——这没问题；但如果共用同一个 *os.File，Seek 会相互覆盖，导致读错数据。

立即学习“go语言免费学习笔记（深入）”；

• 每个 goroutine 必须独立 os.Open 同一个文件，而不是传入同一个 *os.File
• 不要在 goroutine 里反复 Seek + Read 小块数据，IO 开销大；改用 io.ReadFull 一次性读够分片大小
• linux 下单个文件可被多个进程/线程同时 open，但 Windows 对只读文件有时会加共享锁，记得用 os.O_RDONLY|os.O_SHARE_DELETE（需 syscall）绕过

断点续传真正的复杂点不在 Seek 本身，而在于你怎么把“本地文件偏移”、“HTTP Range 起始”、“服务端存储位置”、“失败重试时的状态恢复”这四件事串成一条不丢不重的链。少一环，就不是续传，是重传或者漏传。