不能直接用interface{}定义驱动接口，因为它丧失类型安全、ide支持和编译期校验，迫使调用方手动类型断言并承担panic风险；正确做法是定义最小契约接口（如put/get/delete/exists），由各驱动自行实现，上层代码完全解耦底层存储类型。
为什么不能直接用 interface{} 定义驱动接口
Go 的接口设计核心是“小而精”，如果用 interface{} 作为驱动抽象，会失去类型安全和 IDE 支持，调用方必须手动断言、处理 panic，也难以做编译期校验。真正该做的是定义一组最小契约方法，让每个驱动自己决定内部如何实现。
比如存储驱动至少要暴露 Put、Get、Delete 和 Exists —— 这四个方法覆盖了绝大多数读写场景。所有驱动都实现这个接口，上层代码就完全不关心底层是本地文件、S3 还是内存缓存。
- 接口定义应避免带上下文（
context.Context）参数：它属于调用侧控制权，不应硬编码进驱动契约；实际使用时由调用方包装 - 错误返回统一用自定义错误类型（如
ErrNotFound），方便上层用errors.Is(err, storage.ErrNotFound)判断，而不是字符串匹配 - 不要在接口里暴露初始化逻辑（如
NewS3Driver(...)），那是工厂函数的事
如何注册和获取不同驱动实例
Go 没有全局注册表机制，硬写 map[string]Driver 容易引发竞态或初始化顺序问题。更稳妥的做法是显式传入驱动实例，或用选项模式封装构造过程。
推荐用函数选项（functional options）初始化主库，例如：
type Storage struct {
driver Driver
}
func NewStorage(opts ...StorageOption) *Storage {
s := &Storage{}
for _, opt := range opts {
opt(s)
}
return s
}
type StorageOption func(*Storage)
func WithDriver(d Driver) StorageOption {
return func(s *Storage) {
s.driver = d
}
}
- 调用方可以清晰看到依赖了哪个驱动：
NewStorage(WithDriver(NewMemoryDriver())) - 测试时可直接注入 mock 驱动，无需修改注册逻辑
- 避免 init() 函数隐式注册，防止单元测试间污染
本地文件驱动要注意路径和权限问题
os.OpenFile 在 Windows 和 Linux 下对路径分隔符、权限掩码的处理不一致，直接拼接 filepath.Join(base, key) 不够，还必须做安全校验，否则可能被路径遍历攻击（如 key = "../../etc/passwd"）。
- 务必用
filepath.Clean()+strings.HasPrefix()检查是否仍在 base 目录内 - 写入前确保父目录存在：
os.MkdirAll(filepath.Dir(fullPath), 0755) - Linux 下注意 umask 影响，显式设置
0644而非依赖系统默认 - Windows 上
os.RemoveAll对正在使用的文件会失败，需加重试或跳过
S3 驱动如何复用 AWS SDK v2 的凭据链
AWS SDK v2 的 config.LoadDefaultConfig 本身已支持环境变量、~/.aws/credentials、EC2 实例角色等多种凭据源，强行自己解析 AWS_ACCESS_KEY_ID 反而破坏兼容性。
正确做法是把 aws.Config 作为依赖传入 S3 驱动构造函数：
type S3Driver struct {
client *s3.Client
bucket string
}
func NewS3Driver(cfg aws.Config, bucket string) *S3Driver {
return &S3Driver{
client: s3.NewFromConfig(cfg),
bucket: bucket,
}
}
- 调用方负责加载配置（可加自定义 resolver 或 region 设置），驱动只专注业务逻辑
- 避免在驱动内部调用
config.LoadDefaultConfig(context.TODO(), ...)——TODO会掩盖超时控制需求 - S3 的
HeadObject响应没有 Content-Type 时，Get可能返回空 body，需检查result.Body是否为 nil
