本文详解如何使用 goamz 实现 http 响应流的分块读取与 s3 多部分上传，解决 `io.readcloser` 无法直接满足 `s3.readeratseeker` 接口要求的问题，适用于 2gb+ 大文件的内存友好型直传场景。
Goamz 的 multi.PutAll 方法要求传入一个实现了 s3.ReaderAtSeeker（即同时满足 io.ReaderAt 和 io.ReadSeeker）的参数，但 http.Response.Body 仅是 io.ReadCloser，不支持随机读取或回溯 —— 这在多部分上传中是必需的（因 PutAll 内部需多次 seek 并分片读取）。直接包装 resp.Body 为 ReaderAtSeeker 不可行（数据不可重放），因此必须放弃 PutAll，转而采用更可控、更符合流式语义的 multi.PutPart 手动分块上传方案。
以下是完整、健壮的实现思路与代码：
✅ 核心策略：手动分块 + PutPart
- 预获取文件大小：从 Content-Length 头确定总长度（若缺失，需先 HEAD 请求确认，或改用分块缓冲策略）；
- 按 5MB+ 分片（S3 最小分片为 5MB，goamz 默认 PutPart 推荐 ≥5MB）；
- 逐片读取 resp.Body → 缓存为 []byte → 构造 bytes.Reader → 调用 multi.PutPart；
- 收集所有 Part 信息后调用 multi.Complete。
// 获取 Content-Length（关键！）
contentLen := resp.ContentLength
if contentLen <= 0 {
log.Fatal("Content-Length missing or invalid; multi-part upload requires known size")
}
const partSize = 5 * 1024 * 1024 // 5MB minimum for S3
numParts := int((contentLen + partSize - 1) / partSize)
// 初始化 multipart upload
multi, err := bucket.InitMulti(s3Path, "text/plain", s3.Private, s3.Options{})
if err != nil {
log.Fatalf("InitMulti failed: %v", err)
}
var parts []s3.Part
// 逐片上传
buf := make([]byte, partSize)
for i := 0; i < numParts; i++ {
// 计算本片实际读取长度
remaining := contentLen - int64(i)*partSize
readSize := int64(partSize)
if remaining < partSize {
readSize = remaining
}
// 读取 exactly `readSize` 字节
n, err := io.ReadFull(resp.Body, buf[:readSize])
if err != nil && err != io.ErrUnexpectedEOF {
log.Fatalf("ReadFull failed at part %d: %v", i+1, err)
}
if n != int(readSize) {
log.Fatalf("Short read: expected %d, got %d", readSize, n)
}
// 构造 bytes.Reader（满足 io.Reader + io.ReaderAt + io.Seeker）
r := bytes.NewReader(buf[:n])
// 上传该分片
part, err := multi.PutPart(i+1, r, int64(n))
if err != nil {
log.Fatalf("PutPart %d failed: %v", i+1, err)
}
parts = append(parts, part)
log.Printf("Uploaded part %d/%d (%d bytes)", i+1, numParts, n)
}
// 完成上传
if err := multi.Complete(parts); err != nil {
log.Fatalf("Complete failed: %v", err)
}
log.Printf("Upload completed successfully: %s", s3Path)⚠️ 注意事项与最佳实践
- Content-Length 必须存在：Chunked Transfer-Encoding 响应无 Content-Length，此时需先发起 HEAD 请求获取真实大小，或改用临时磁盘/内存缓冲（如 ioutil.TempFile + os.File，它天然满足 ReaderAtSeeker）。
- 错误处理要精细：io.ReadFull 比 io.Read 更可靠，避免因网络波动导致分片不完整；上传失败时建议调用 multi.Abort() 清理未完成上传。
- 内存控制：上述示例使用固定 5MB 缓冲区，内存占用恒定（不随文件增大），符合“流式”设计初衷。
- 替代方案提示：若未来迁移到官方 AWS SDK for Go v2，可直接使用 manager.Uploader，其 Upload 方法原生支持 io.Reader 流式上传，无需手动分片。
综上，面对 http.Get 响应流与 goamz 多部分上传的接口鸿沟，不强行适配 ReaderAtSeeker，而是拥抱流式本质、手动分块上传，才是简洁、高效、可维护的正解。
