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 起始”、“服务端存储位置”、“失败重试时的状态恢复”这四件事串成一条不丢不重的链。少一环，就不是续传，是重传或者漏传。 
