必须手动定义统一接口（如Storage或FileStore），收敛Get/Put/Delete/Exists等语义，归一化错误，隔离各后端细节；os.File和io/fs.FS因绑定系统特性或缺失写入/删除能力，无法直接支撑多后端抽象。
不能靠“语言学习”实现多存储后端——Go 本身不提供跨存储抽象，必须手动定义接口、收敛错误、隔离驱动细节。所谓“学习语言”只是误读，真正要做的，是用 Go 的 interface + 组合 + 错误归一化，把本地磁盘、S3、内存等后端统一到同一套契约下。
为什么 os.File 和 io/fs.FS 都不能直接用于多后端
os.File 绑定操作系统文件描述符，io/fs.FS 只读且无写入/删除语义——两者都缺失对对象存储（如 S3）的关键支持：无 PutObject 对应操作、无法处理 404 NoSuchKey 与 os.ErrNotExist 的语义等价、也不支持带 context 的超时控制。硬套用只会让代码在切换后端时大面积重写。
-
os.Open返回的*os.File无法被 S3 驱动实现，因为 S3 没有“打开句柄”的概念 -
io/fs.FS的Open方法签名是func(string) (fs.File, error)，但fs.File接口只含Stat和Read，缺Write、Delete、Exists - 所有基于
io/fs.FS的封装（如http.FileSystem）都默认面向只读静态资源，不适合文件管理类业务
定义最小可行 FileSystem 接口的关键取舍
别一开始就模仿完整 POSIX，从最常调用的四个动作切入：Open、Stat、WriteFile、Remove。路径语义统一为 string，错误全部映射到自定义类型（如 fs.ErrNotExist），而非裸抛底层 SDK 错误。
-
Open(path string)返回自定义File接口，只需嵌入io.ReadCloser；写操作交给FileSystem.WriteFile，避免流式写入生命周期混乱 -
Stat不返回os.FileInfo，而是自定义FileInfo，只保留Name()、Size()、ModTime()、IsDir()四个方法 - 所有
path参数不自动 trim 开头/，交由各驱动解释：本地驱动可补./，S3 驱动统一转/为key分隔符 - 拒绝在接口里暴露后端特有字段（如 S3 的
Acl、本地的perm），这些应通过构造函数或配置传入
本地驱动最容易踩的三个坑
看似简单，实则线上事故高发区：路径穿越、符号链接误解析、非原子写入。不用 os.WriteFile 或 ioutil.WriteFile（已弃用），而要用临时文件 + os.Rename 保证原子性。
立即学习“go语言免费学习笔记（深入）”；
- 输入
path必须过filepath.Clean()，再检查是否以".."开头，否则../../../etc/passwd可逃逸根目录 -
Stat必须用os.Lstat而非os.Stat，否则符号链接会被跟随，导致路径解析错乱 -
WriteFile应先写入filepath.Join(dir, "."+base+".tmp")，再os.Rename替换原文件，避免写入中途崩溃留下脏数据 - 创建父目录用
os.MkdirAll(filepath.Dir(path), 0755)，别假设目录一定存在
S3 驱动必须处理的协议差异
AWS SDK 默认行为不等于 S3 兼容服务（MinIO、OSS、COS）的实际要求。endpoint、region、signing name 必须显式对齐，否则 403 错误频发，且无法靠“试错”定位。
-
region值必须严格匹配云厂商文档 ID（如阿里云填oss-cn-hangzhou，不是cn-hangzhou） -
signingName必须设为"s3"，即使对接 OSS 或 COS，否则 SDK 尝试用非标签名导致 403 -
endpoint必须带协议（https://），且不含 bucket 名；错误示例：https://my-bucket.oss-cn-hangzhou.aliyuncs.com→ 正确应为https://oss-cn-hangzhou.aliyuncs.com -
HeadObject404 要转成fs.ErrNotExist，不能直接返回aws.Error.Code == "NotFound"；DeleteObject单文件别滥用DeleteObjects批量接口
真正麻烦的从来不是写几个 if cfg.Type == "s3"，而是错误映射是否彻底、路径清洗是否覆盖边界 case、并发写入时临时文件名是否唯一、以及 client 实例是否复用——这些细节没压住，多后端就只是个幻觉。
