不该从零封装多云对象存储SDK，因各厂商PutObject语义、错误码、分片流程差异大，硬统一易漏功能或滥用map[string]interface{}；应采用适配器模式，定义最小接口ObjectStorage，分厂商独立实现，隔离细节。
为什么不该从零封装多云对象存储 SDK
直接写一个“统一”sdk 看似省事，实际会掉进抽象陷阱：各厂商的 putobject 语义差异大（比如 aws s3 的 serversideencryption 和 aliyun oss 的 oss.serversideencryption 参数名、取值、生效条件全不同），错误码不互通（s3.errcodenosuchbucket vs oss.nosuchbucket），甚至分片上传流程阶段数都不同。硬套一层 interface 最终要么漏功能，要么塞满 map[string]interface{} 让调用方自己猜字段。
推荐做法：用适配器 + 标准接口隔离厂商细节
定义最小可行接口（如 ObjectStorage），只暴露真正共有的行为：读、写、删、列出前缀、生成预签名 URL。每个厂商用独立包实现该接口，不共享代码逻辑：
-
aws/s3adapter：用官方github.com/aws/aws-sdk-go-v2/service/s3，注意设置UsePathStyle兼容 MinIO -
aliyun/ossadapter：用github.com/aliyun/aliyun-oss-go-sdk/oss，注意Endpoint必须带协议（https://oss-cn-hangzhou.aliyuncs.com），否则初始化失败 -
gcp/storageadapter：用cloud.google.com/go/storage，认证依赖GOOGLE_APPLICATION_CREDENTIALS环境变量，不能靠 access key 模拟
调用方按需导入对应 adapter，传入配置后得到统一接口实例——不是“一套代码跑所有云”，而是“一套接口，多套实现”。
预签名 URL 是最容易出错的兼容点
各厂商对临时 URL 的签名有效期、HTTP 方法限制、query 参数要求完全不同：
-
AWS S3：用s3.PresignPutObject，Expires单位是time.Duration，必须 ≥ 15 分钟（否则报SignatureDoesNotMatch） -
Aliyun OSS：用bucket.SignURL，expires是 int 秒，最大 64800（18 小时），超时返回InvalidArgument -
GCP：不支持客户端直签，必须走服务端SignBlob或用storage.SignedURLOptions配合 IAM service account key，且 URL 有效期上限 12 小时
如果业务强依赖预签名，别试图统一参数名，直接在 adapter 层把 GeneratePresignedPutURL(key string, expires time.Duration) 接口拆成两版：GeneratePresignedPutURLV1（S3/OSS 兼容）和 GeneratePresignedPutURLV2（GCP 专用），避免隐藏的时区或精度问题。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
ListObjects 分页逻辑必须各自实现
ListObjects 在各厂商中根本不是同一件事：
-
S3：用list-objects-v2，靠ContinuationToken分页，响应里有NextContinuationToken -
OSS：用ListObjects，靠marker（字符串游标），响应里是NextMarker，且首次请求 marker 必须为空字符串，不能为 nil -
GCP：用Objects.List，靠PageToken，但返回的NextPageToken是 base64 编码字符串，需原样透传，不可 decode
不要在上层封装一个 “通用分页器”。每个 adapter 实现自己的 Pager 类型，调用方迭代时只管调 pager.Next()，内部自动处理 token 类型转换和空值边界。否则你会在凌晨三点 debug 为什么 OSS 列表卡在第 999 个文件——因为 marker 传了 nil 而不是 ""。
真正的难点不在怎么写，而在决定哪些东西**不统一**。留白比填满更难，也更重要。
