GridFS不是本地磁盘替代品，仅在需跨节点同步元数据与二进制、原子备份或规避文件系统目录项限制时才适用；必须选GridFS的场景包括：依赖副本集多机房同步、mongodump全量灾备要求版本一致、单目录超百万小文件、需byte range随机读取大文件；坚决不能用的场景包括：频繁追加写、需POSIX语义、单文件＜16MB、高吞吐小文件写入。
GridFS 不是本地文件系统的替代品，它只在特定条件下比直接写磁盘更可靠或更可控——比如你需要跨节点同步元数据与二进制、做原子备份、或规避文件系统目录项数量限制时，才值得用。
什么时候必须选 GridFS 而不是本地磁盘
常见错误现象：用 NFS 或共享目录做“分布式文件存储”，结果出现权限不一致、缓存延迟、删除后文件残留；或者用 rsync 同步大文件时中断重传失败，导致元数据和实际内容错位。
使用场景中真正需要 GridFS 的只有这几类：
- 文件需随 MongoDB 副本集自动复制到多个机房（比如用户上传的视频要实时在华东、华北节点都可读）
- 你依赖 mongodump/mongorestore 做全量灾备，且要求文件和业务数据版本严格一致（例如订单表 + 对应发票 PDF 必须同一次 dump 出来）
- 单目录下预计存超过 100 万个小文件（如日志切片、缩略图），而 ext4/xfs 对单目录 inode 数有硬限制
- 需要按 byte range 随机读取大文件某一段（比如跳转播放 2GB 视频的第 90 分钟），且不想自己实现分块索引和 HTTP Range 处理逻辑
什么时候坚决不能用 GridFS
常见错误现象：用 uploadFromStream 往 GridFS 写日志流，结果 chunks 集合暴涨、查询变慢；或把数据库备份文件（mongodump --archive 输出）塞进 GridFS，之后发现无法用 mongorestore 直接读取。
以下情况请直接写本地磁盘或对象存储：
- 文件内容会频繁追加（如实时日志、传感器数据流）——GridFS 不支持 append，每次“更新”都是新文档 + 旧数据残留
- 需要 POSIX 文件语义（
open()/flock()/rename()）——GridFS 没有文件锁、没有硬链接、不能ls查目录树 - 单文件稳定小于 16MB ——直接用
BinData存进普通 collection 更快，避免多集合 join 和 chunk 拼接开销 - 高吞吐小文件写入（如每秒 1000+ 张 200KB 图片）——GridFS 默认 255KB/chunk，意味着每张图至少生成 1 个
fs.files+ 1 个fs.chunks文档，IO 放大严重
并发上传同名文件怎么不出错
常见错误现象：ENOENT 报错但 db.fs.files.find({filename: "report.pdf"}) 能查到多条记录；下载文件内容为空或截断。
根本原因在于 GridFS 没有“覆盖写”语义，put() 或 openUploadStream() 传相同 filename 会新建 files 记录，但旧 chunks 不删，驱动读最新 files_id 对应的 chunks 时可能已损坏。
安全做法只有两条路：
- 业务层强制用唯一 ID（如
user_id:file_id）作为metadata.fileId，并在fs.files上建唯一索引：db.fs.files.createIndex({ "metadata.fileId": 1 }, { unique: true }) - 若必须用 filename，上传前必须显式删除旧记录：先
findOne({filename: "x"})拿到_id，再用事务执行deleteOneonfs.files和deleteManyonfs.chunks（注意：GridFS 本身不支持事务，但 MongoDB 4.0+ 可对底层集合操作加事务）
最易被忽略的一点：GridFS 的 chunkSize 一旦设错就很难改——改小会导致已有文件读取失败（驱动按旧 size 拼接），改大会让小文件读取变慢。生产环境建议保持默认 255KB，除非你明确知道所有文件都在 500KB–2MB 区间，才考虑统一调成 512KB。
