不能直接混用 minio-go 和 aws-sdk-go，因接口不一致、错误类型不可互转、配置重复、测试难 mock；应定义统一 objectstorage 接口，封装差异至具体实现，并用通用配置与轻量 fake 实现可测性。
为什么不能直接用 minio-go 和 aws-sdk-go 两套客户端混着写
因为业务代码里一旦同时依赖 minio-go 和 aws-sdk-go，就会面临接口不一致、错误类型不可互转、配置结构重复、测试难 mock 等实际问题。比如 PutObject 在两个 SDK 里参数顺序不同，minio-go 要传 io.Reader + size，而 aws-sdk-go 的 PutObjectInput 里 Body 是 io.ReadSeeker，且 ContentLength 是可选字段——不统一封装，后续换存储后端或加缓存层时，改起来就是全量搜索替换。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 定义统一的接口（如
ObjectStorage），只暴露Upload(ctx, key, reader, size)、Download(ctx, key)、Delete(ctx, key)这类语义清晰的方法 - 避免在接口中暴露 SDK 特有类型（如
*s3.GetObjectOutput或minio.ObjectInfo），一律用自定义结构体（如ObjectMeta{Key, Size, ModTime}） - 错误统一为自定义错误类型（如
ErrNotFound、ErrPermissionDenied），不直接返回minio.ErrInvalidBucketName或awserr.Error
如何让 MinIO 和 S3 实现共用同一套外观逻辑
关键不是“适配器拼凑”，而是把差异收口到具体实现里：MinIO 客户端走 HTTP 直连，S3 客户端走 AWS v2/v3 SDK，但对外都满足同一个 ObjectStorage 接口。真正的难点在初始化和凭证传递——MinIO 通常用 AccessKey/SecretKey + Endpoint，而 S3 可能走 IAM Role、Web Identity 或 Shared Config。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 构造函数接收通用配置结构体（如
StorageConfig{Endpoint, Region, Bucket, AccessKey, SecretKey, UseSSL}），内部根据Endpoint是否包含"s3."或是否设置了Region自动判别后端类型 - MinIO 实现里必须显式调用
client.SetCustomTransport(...)关闭证书校验（开发环境常见），而 S3 实现要复用config.WithRegion和config.WithCredentials，不能硬编码credentials.NewStaticCredentials - 上传时统一处理
size == -1场景：MinIO 要求明确 size，S3 允许流式上传；此时外观层应先尝试io.Seek，失败则用io.Copy+bytes.Buffer缓存（仅限小文件）
Download 方法里容易忽略的流式读取陷阱
外观层如果直接返回 io.ReadCloser，调用方忘记 Close() 就会导致连接泄漏——MinIO 的 GetObject 返回的是带连接池的响应体，S3 的 GetObject 同样依赖底层 HTTP 连接复用。更隐蔽的问题是：S3 SDK 默认会把整个对象读进内存再返回 Body，而 MinIO 默认是流式；若外观层不做对齐，下游行为就不可预测。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
Download不返回裸io.ReadCloser，而是返回封装后的*DownloadResult，含Body io.ReadCloser和Close() error方法，强制调用方显式释放 - MinIO 实现中，直接透传
minio.Object的Close()；S3 实现中，在Close()里手动调用resp.Body.Close()，并检查是否已读完（未读完时 S3 会静默丢弃剩余数据） - 避免在外观层做自动解压或格式转换（如 gzip），那是业务层的事；但可以加一个
WithDecompress(bool)选项供调用方按需开启
测试时怎么绕过真实网络请求又覆盖两种后端逻辑
单元测试不能每次都起 MinIO 容器或配 AWS 凭证。但只 mock 接口又测不到实现类里对 SDK 的误用（比如忘了设 minio.WithRegion 导致签名失败）。真正有效的办法是：为每个实现写一个轻量 fake，不走网络，但保留关键路径分支。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- MinIO fake：用
map[string][]byte模拟存储，GetObject返回io.NopCloser(bytes.NewReader(data))，并在Close()里记录是否被调用 - S3 fake：不用
aws-sdk-go的mock包（太重），而是实现s3iface.S3API接口，所有方法只做参数校验和固定返回，比如PutObject校验input.Bucket == "test-bucket"，否则 panic - 在测试 setup 中，用
func NewStorage(config StorageConfig) (ObjectStorage, error)创建实例，config 的Endpoint设为"http://fake-minio.local"或"https://fake-s3.amazonaws.com"，外观层据此路由到对应 fake
最麻烦的其实是并发上传时的 key 冲突和 Delete-then-Upload 时序问题——这些没法靠单测全覆盖，得靠集成测试跑真实 MinIO 容器。外观模式本身不解决一致性，它只是让这类问题集中在一个包里暴露，而不是散落在二十个 service 文件里。
