GridFS 无法直接支持目录层级，因 filename 字段仅为普通字符串，MongoDB 不解析路径语义；需新建 files_meta 集合维护父子关系、类型等元数据，并通过原子操作与 GridFS 协同管理。
GridFS 本身不支持目录结构，所有文件扁平存储，想实现网盘的「文件夹层级」必须自己维护元数据，不能依赖 fs.files 或 fs.chunks 自带字段。
为什么不能直接用 GridFS 的 filename 字段模拟路径
filename 字段只是字符串，MongoDB 不会解析它为路径层级；你存 "photos/vacation/2024.jpg"，GridFS 完全感知不到 photos 是目录、vacation 是子目录——它只当整个字符串是文件名。这意味着：
- 无法高效列出某个目录下的所有子项（得用正则匹配
filename，性能差且无法利用索引） - 重命名目录时需批量更新所有匹配文件的
filename，事务难保证一致性 - 无法区分同名文件在不同目录下的冲突（比如
a/b.txt和c/b.txt在filename上无天然隔离）
推荐的元数据集合设计：files_meta
新建一个独立集合（如 files_meta），每条文档描述一个「文件或目录」实体，与 GridFS 的 fs.files 文档通过 file_id 关联（目录则 file_id: null）。关键字段包括：
-
_id：唯一 ID（可用 ObjectId） -
name：当前项名称（不带路径，如"vacation"） -
parent_id：父节点_id（根目录为null） -
type：值为"file"或"directory" -
file_id：仅当type === "file"时存在，指向fs.files._id -
size、uploadDate等：按需冗余，避免每次查文件都 joinfs.files
这样就能用 { parent_id: ObjectId("...") } 高效查询子项，并支持递归构建路径、校验路径合法性（比如防止循环引用）。
创建/移动/删除操作必须原子更新两个集合
GridFS 没有原生事务跨集合能力（即使在 4.0+ 支持多文档事务，也要求所有集合在同数据库且开启副本集），因此关键操作要谨慎：
- 上传新文件到
/docs/report.pdf：先插入files_meta目录节点（docs）、再插入文件节点，最后调用gridFSBucket.uploadFromStream()；任一失败需回滚已写入的元数据 - 移动文件
a/x.txt → b/x.txt：需同时更新files_meta中该文件的parent_id和name（若重命名），并确保目标路径下无同名冲突——这步必须用findOneAndUpdate加条件（如{ parent_id: b_id, name: "x.txt" }不存在） - 删除非空目录：先递归查子项（用聚合管道 +
$graphLookup），确认为空再删；否则需级联删除，建议用后台任务而非单次请求完成
查询某路径下的全部内容（含子目录和文件）
不要拼接 filename 正则，改用 $graphLookup 一次性展开：
db.files_meta.aggregate([
{ $match: { parent_id: ObjectId("root_id") } },
{
$graphLookup: {
from: "files_meta",
startWith: "$_id",
connectFromField: "_id",
connectToField: "parent_id",
as: "descendants",
maxDepth: 5,
depthField: "depth"
}
},
{ $unwind: "$descendants" },
{ $replaceRoot: { newRoot: "$descendants" } },
{ $sort: { "type": 1, "name": 1 } }
])
这个聚合能返回指定目录及其所有后代（含嵌套多层），配合 $project 可补全完整路径（如拼接 parent.name + "/" + name）。注意 maxDepth 要设合理上限，避免意外遍历过深。
真正麻烦的是权限控制和硬链接场景——比如用户 A 共享 /shared 给用户 B，B 看到的其实是同一组 files_meta 文档，但需额外字段（如 owner_id、shared_with）隔离视图，这部分没法靠 GridFS 自身解决，得在业务层兜底。
