因为 httputil.NewSingleHostReverseProxy 仅支持 HTTP/1.1 协议，无法解析 FTP 命令、S3 REST 语义、OAuth2 授权或二进制流协议；它依赖 http.Request.Body，而多平台存储需统一抽象为 afero.Fs 接口，并适配各后端行为差异与基础设施约束。
为什么直接用 httputil.NewSingleHostReverseProxy 无法支撑多平台存储网关
它只处理 HTTP/1.1，对 FTP、SFTP、S3、Google Drive 这类非 HTTP 协议完全无感知。一旦你试图用它转发 FTP 命令或 S3 的 REST 请求，会立刻出现连接重置、400 Bad Request 或空响应——因为底层根本没解析 USER、PASS、STOR 这些 FTP 命令，也不会把 PUT /object 映射成 S3 的 PutObject 调用。
更关键的是，ReverseProxy 强依赖 http.Request.Body，而 FTP/SFTP 是二进制流协议，gRPC 是帧格式，Dropbox API 又要求 OAuth2 token 放在 header，这些都无法靠简单“改 Host + 转发”搞定。
- FTP 协议需要独立的 TCP listener + 命令状态机（如
ftpserver库） - S3 后端必须走
afero-s3实现的afero.Fs接口，而非 HTTP client - Google Drive 和 Dropbox 必须完成 OAuth2 授权流程，token 要持久化并自动刷新
- 所有后端操作必须统一抽象为
Open、Read、Write、Mkdir等方法，否则无法共用同一套 FTP 协议层
afero.Fs 是统一存储抽象的核心，但不是万能胶水
它确实屏蔽了本地磁盘、S3、SFTP 等后端差异，但不同实现的行为边界差异极大：
-
afero-os支持硬链接、chmod、chown；afero-s3完全不支持，调用会静默失败或 panic -
afero-gdrive的Readdir默认只返回前 100 项，需手动分页；而afero-s3的ReadDir是完整 listObjectsV2 -
afero-dropbox对文件名长度、路径深度有严格限制（如不能含\、路径最多 8 层），本地 fs 却完全宽松 - 所有
afero.Fs实现都不保证原子性Rename：S3 是 copy+delete，GDrive 是 move，本地 fs 才是真 rename
所以你在写网关逻辑时，不能假设 os.Rename 等价于 fs.Rename；上传大文件时也不能直接 io.Copy(fs.Create(...), req.Body)，得按后端能力切片、分块、带进度回调。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
配置多后端时，fs 字段和 params 结构必须严格匹配插件约定
每个后端适配器对 JSON 配置字段名、类型、必填性都有硬性要求，拼错一个 key 就会导致初始化失败且错误信息极不友好（比如 afero-s3 报 missing bucket，但你实际写的是 bucket_name）。
- S3 后端必须用
"fs": "s3"，且params中bucket、region、access_key_id、secret_access_key全为字符串；path_style是布尔值，不是字符串"true" - Google Drive 要求
"fs": "gdrive"，且params.google_client_id和params.google_client_secret必须提前在 GCP 控制台创建 OAuth2 凭据；base_path是可选字符串，表示挂载根目录 - 本地磁盘用
"fs": "os"，params.basePath是绝对路径，且进程必须有读写权限；若路径不存在，afero-os不会自动创建 - 多个用户共享同一份配置时，务必用
accesses数组，每个对象独立定义user、pass、fs和params，不能共用一套 credentials
常见坑：params 里混用下划线和驼峰（如 access_key vs accessKey）、把布尔值写成字符串、漏掉 region（S3 默认 us-east-1，但中国区必须显式设 cn-north-1）。
被动模式 FTP 端口范围与云环境 NAT 网关必须协同配置
FTP 被动模式（PASV）需要客户端连回服务器开放的一组端口，但在 Kubernetes 或阿里云 SLB 下，这些端口默认被拦截。光在配置里写 "passive_transfer_port_range": { "start": 2122, "end": 2130 } 不够。
- Docker 部署时，必须用
-p 2121-2130:2121-2130映射整个端口段，不能只映射 21 - K8s Service 类型必须是
LoadBalancer或NodePort，且nodePort要覆盖 PASV 端口范围 - 云厂商安全组要放行 PASV 端口段（如阿里云需在入方向加 2122–2130 TCP 规则）
- FTP 客户端看到的 PASV 响应 IP 必须是公网 IP，不是容器内网 IP；需配置
public_ip字段或通过PassiveIP选项强制指定
否则现象是：LIST 命令卡住、STOR 失败、FileZilla 报 Connection timed out after 20 seconds of inactivity——问题不在代码，而在基础设施层漏配。
