Golang集成文件存储SDK实现对象上传进度监控-Golang-PHP中文网

progressreader必须包装原始文件流而非直接包装os.file或http.request.body，因sdk内部多次read、seek或重试会导致读取错位或eof提前；正确做法是每次上传新建os.file或先完整读取request.body到内存/临时文件再包装。

golang集成文件存储sdk实现对象上传进度监控

ProgressReader 必须包装原始文件流，不能包装 *os.File 或 http.Request.Body 直接传入

Go 的对象存储 SDK（如阿里云 OSS、MinIO）上传接口要求传入 io.Reader，但它们内部会多次调用 Read 方法，甚至可能 seek 或重试。如果直接把 *os.File 或 http.Request.Body 包进 ProgressReader 后复用，会导致读取错位或 EOF 提前触发。

正确做法是：每次上传都新建一个 *os.File，用 os.Open 打开，并立即包进 ProgressReader；若来自 HTTP 请求，则需先将 Request.Body 完整读到内存或临时文件再包装——否则后续 multipart 解析或 SDK 内部重试会失败。

ProgressReader 的 file 字段应为 io.Reader 类型，不是具体实现类（如 *os.File），方便适配不同来源
回调函数里别做阻塞操作（如写日志到磁盘、发 HTTP 请求），否则拖慢上传速度
注意 Read 方法可能返回 n == 0 && err == nil（空读），此时不应更新进度

阿里云 OSS SDK 的 PutObjectFromFile 不走 ProgressReader，必须用 PutObject + 自定义 Reader

很多人误以为 PutObjectFromFile 支持进度回调，其实它底层是先读文件到内存再一次性上传，不经过用户可控的 Read 流程，所以无法注入 ProgressReader。真正能监控进度的只有 PutObject 接口，它接受 io.Reader 参数。

示例中常见错误是传入 os.Open("x.jpg") 而不包装，结果进度始终为 0 —— 因为没触发回调；或者传了包装后的 Reader，但忘了设置 total（文件大小），导致百分比计算失效。

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

调用 PutObject 前，务必用 os.Stat 获取文件 Size() 并赋给 ProgressReader.total
OSS 默认超时极短，大文件上传易卡在 PutObject 返回前，必须显式加 oss.Timeout(120 * time.Second)
若用 resumableUpload 模块，它内部会分片并多次调用 Read，此时 ProgressReader 仍有效，但总进度需按分片累加，不能只看单次 Read

MinIO 客户端上传进度监控和 OSS 几乎一致，但 multipart 上传需额外处理 boundary

MinIO 兼容 S3 API，PutObject 行为与 OSS 一致，同样依赖 io.Reader 注入进度逻辑。但如果你走的是 PutObjectMultipart（比如大文件自动分片），SDK 会自己构造 multipart/form-data 请求体，这时你无法直接控制 Body 的读取过程 —— 进度监控就得退回到服务端解析阶段，或改用客户端手动分片 + 单个 PutObject 调用。

另一个坑是：MinIO 的 Go SDK 对 Content-Length 更敏感。如果 ProgressReader.total 和实际文件大小不符，上传可能中途被拒绝，报错类似 SignatureDoesNotMatch 或 InvalidRequestBody。

用 minio.PutObjectOptions 时，不要设 ContentType 为 "multipart/form-data" —— 这是表单上传用的，对象直传应设为文件真实 MIME 类型（如 "image/jpeg"）
MinIO 的 PutObject 不支持断点续传，大文件必须自己切片 + StartGetObject/PutObjectPart 配合 ProgressReader 分段监控
本地调试时，MinIO server 日志默认不打印上传字节数，需加 --console-address :9001 并查 Console UI 的 network tab 确认是否真在发数据

上传完成 ≠ 进度回调结束，要检查 err 是否为 io.EOF

很多实现把 update 回调放在 Read 方法末尾，但最后一次 Read 可能返回 n > 0 && err == io.EOF，也可能返回 n == 0 && err == io.EOF。前者是正常结束，后者可能意味着流提前中断 —— 比如网络断开、文件被删、或 SDK 内部重试失败。

更隐蔽的问题是：某些 SDK（尤其是封装了缓冲的）会在最后一次 Read 后多调一次 Read 来确认 EOF，这时 pr.read 已等于 pr.total，但回调又触发一次 100%，造成重复日志或 UI 跳变。