gridfs 不能用 filename 模拟目录，因其不解析斜杠语义，导致查询无法走索引、重命名需批量更新、同名文件易冲突；应新建 files_meta 集合维护层级关系，字段含 name、parent_id、type、file_id 等，并在操作中手动校验路径合法性与循环引用。
GridFS 本身不支持目录树，强行用 filename 字段存路径（如 "docs/report.pdf"）会导致查询慢、重命名难、冲突不可控——必须额外建集合维护层级关系。
为什么不能直接靠 filename 模拟目录
GridFS 的 filename 是纯字符串字段，MongoDB 不解析斜杠语义。你写 "a/b/c.txt"，它只当整个串是文件名，不会自动拆出父目录或生成层级索引。
- 查
"a/b/"下所有文件？只能用正则{ filename: { $regex: "^a/b/.*" } }，无法走索引，数据量一上来就卡 - 把
"a/b/"改成"x/y/"？得批量更新所有匹配文档的filename，没事务兜底，容易漏或错 -
"a/c.txt"和"b/c.txt"在fs.files里都叫"c.txt"，但实际是不同文件——filename不具备唯一性上下文
应该建哪个集合、存哪些字段
新建一个独立集合，比如叫 files_meta，每条文档代表一个「节点」（文件或目录），和 GridFS 解耦：
-
_id：用ObjectId，作为节点唯一 ID -
name：当前项名称，不含路径（如"report.pdf"或"docs"） -
parent_id：指向父节点的_id；根目录设为null -
type：值为"file"或"directory" -
file_id：仅当type === "file"时存在，对应fs.files._id，用于关联 GridFS 实体 -
size、uploadDate等：按需冗余，避免每次查文件都要去fs.files聚合
这样查某个目录下的子项，就是简单的一次查询：{ parent_id: ObjectId("...") }，加个索引就能秒出。
上传/移动/删除操作必须跨集合协同
GridFS 和 files_meta 是两个集合，MongoDB 多文档事务要求同库+副本集，且不能跨数据库。生产环境别指望靠事务自动兜底，得自己控制流程：
- 上传新文件到
/docs/report.pdf：先递归检查并创建docs目录节点（若不存在），再插入文件节点，最后调用gridFSBucket.uploadFromStream()；任一环节失败，要主动回滚已写的元数据 - 移动
a/x.txt → b/x.txt：用findOneAndUpdate原子更新该文件节点的parent_id和name，同时加条件校验目标路径下无同名冲突（{ parent_id: b_id, name: "x.txt" }不存在） - 删非空目录：不能直接删。先用聚合管道 +
$graphLookup查所有后代节点，确认为空才删；否则得走后台任务级联清理，避免请求超时
最容易被忽略的细节
很多人建完 files_meta 就以为万事大吉，但真正上线后才发现：路径合法性没校验（比如 ../../../etc/passwd 这种穿越路径）、循环引用没防住（A 的父是 B，B 的父又指回 A）、parent_id 更新后没同步清理旧路径缓存。这些不是“功能做完就跑”，而是每个写操作前都得过一遍校验逻辑——它不在 GridFS 里，得你自己补上。
