Nginx 不该直接存文件，因其非存储系统，仅是高效代理与静态服务工具；本地磁盘方案会导致文件不同步、扩容困难、无统一入口、缺乏元数据与权限控制等硬伤。
直接用 Nginx 做静态资源服务，适合小项目或临时场景；但当文件量增长、需高可用或跨节点共享时，Nginx 就不该再直接读本地磁盘——它得退到“网关”位置，把真实文件交给 FastDFS 或 MinIO 这类专业存储系统来管。
为什么 Nginx 不该自己存文件？
Nginx 本身不是存储系统，只是高效反向代理和静态服务工具。靠它挂载多台机器的本地目录，会带来几个硬伤：
- 文件无法自动同步：上传到 A 机，B 机查不到，除非额外加 rsync 或 NFS，运维成本陡增
- 扩容困难：加新服务器就得重新配置 Nginx 的 location 和 root 路径，容易出错
- 无统一访问入口：每个节点路径不一致，前端 URL 难管理，CDN 回源也难对齐
- 缺乏元数据与权限控制：比如按用户隔离、文件过期、访问日志归因等，Nginx 原生不支持
FastDFS + Nginx 的经典组合怎么搭？
这是老派但依然有效的方案，特别适合已有大量小图、缩略图且追求极致上传速度的场景（比如电商商品图）。它的核心是让 Nginx 变成 Storage 节点的“本地加速器”。
- Storage 节点上安装 fastdfs-nginx-module 模块，把 FastDFS 内部的 file_id 映射为可访问的 URL 路径（如 /group1/M00/00/00/xxx.jpg）
- Nginx 配置 location 匹配该路径前缀，通过模块直接从本地磁盘读取对应文件，绕过 FastDFS 网络层，降低下载延迟
- Tracker 仍负责上传调度，客户端拿到 file_id 后，拼出 Nginx 地址即可直连下载，整个链路无中间转发
- 注意：Nginx 在这里不代理请求，而是作为 Storage 的“旁路 Web 服务”，所以必须每台 Storage 都部署一份
MinIO + Nginx 更推荐的现代做法
MinIO 天然就是 HTTP 服务，自带完整 S3 API 和 Web 控制台，Nginx 在这里角色更清晰：做反向代理、HTTPS 终结、限流、缓存或跨域控制。
- 不用改 MinIO 源码或编译模块，Nginx 只需简单配置 proxy_pass 指向 MinIO 服务地址（如 http://minio-cluster:9000）
- 可统一用 Nginx 做证书卸载，所有 bucket 访问走同一个域名（如 https://files.example.com/bucket1/key.jpg），后端由 Nginx 路由到对应 MinIO 实例或集群
- 配合 Nginx 的 proxy_cache，还能给热点对象加一层磁盘缓存，减轻 MinIO 压力
- 如果 MinIO 开启了浏览器访问（--console-address），Nginx 也可代理其控制台，统一鉴权入口
选 FastDFS 还是 MinIO？关键看三点
不是技术优劣，而是匹配度：
- 要快速上线、对接云生态、团队熟悉 S3 协议？选 MinIO —— 单命令启动，Java/Python/Go SDK 全覆盖，S3 兼容意味着未来迁阿里云 OSS 或 AWS S3 几乎零改造
- 已有成熟 FastDFS 集群、日均百万级小图上传、对首字节延迟敏感？继续用 FastDFS + Nginx 模块 —— 它在 50KB 级别文件的吞吐上仍有优势，且路径式语义对部分老系统更友好
- 既要小文件性能，又要对象语义和扩展性？可以分层用 —— 比如图片缩略图走 FastDFS，原始大图/视频/备份走 MinIO，Nginx 根据 URL 前缀做路由分发
