GridFS 通过 metadata.path 字段模拟目录结构，需上传时手动设置规范路径（如 /reports/2024/q1），统一编码、斜杠格式，并建索引；查询用 $regex 前缀匹配，删除用 bucket.deleteMany 配合正则。
GridFS 本身不支持目录结构，必须靠 metadata.path 模拟
MongoDB 的 GridFS 是扁平存储，fs.files 集合里没有原生的“文件夹”概念。想实现类似 /reports/2024/q1/sales.pdf 这样的层级查询，唯一可靠方式是在上传时手动把完整路径写进 metadata.path 字段（字符串类型），后续用正则或前缀匹配查。
注意：别用 filename 字段存路径——它只适合单文件名（如 sales.pdf），且 GridFS 驱动对含斜杠的 filename 处理不一致，部分客户端会截断或报错。
上传时正确设置 metadata.path，避免编码和尾部斜杠问题
构造 path 值要统一规范，否则查询会漏匹配。常见坑：
-
path值统一以/开头、不以/结尾（如/reports/2024/q1，不是reports/2024/q1/） - 路径中含中文、空格等需 URL 编码（用
encodeURIComponent或对应语言的 URL-safe 编码函数），否则$regex可能匹配失败 - 不要在
path里混用反斜杠\和正斜杠/，全用/ - Node.js 示例上传片段：
const stream = fs.createReadStream('./sales.pdf'); const bucket = new GridFSBucket(db); const uploadStream = bucket.openUploadStream('sales.pdf', { metadata: { path: '/reports/2024/q1' } }); stream.pipe(uploadStream);
按文件夹查文件：用 $regex 前缀匹配，别用 $eq
查 /reports/2024/q1 下所有文件，不能写 { 'metadata.path': '/reports/2024/q1' }——那只会匹配“刚好等于该路径”的文件（即“文件夹自身”，但 GridFS 里根本没有文件夹文档）。
真正要的是“以该路径为前缀的所有文件”，所以必须用正则：
- 查某一层级下的直接子项（如
/reports/2024/q1/*）：{ 'metadata.path': { $regex: '^/reports/2024/q1/[^/]*$' } } - 查该路径及其所有子路径（递归，如
/reports/2024/q1/**）：{ 'metadata.path': { $regex: '^/reports/2024/q1/' } } - 性能提示：给
metadata.path建索引能显著加速$regex前缀查询：db.fs.files.createIndex({ 'metadata.path': 1 })
删除整个“文件夹”时，必须用 deleteMany + $regex
GridFS 没有 rmdir 操作。删 /reports/2024/q1 目录，本质是删所有 metadata.path 以该字符串开头的文件：
- 先确认范围（安全起见）：
db.fs.files.find({ 'metadata.path': { $regex: '^/reports/2024/q1/' } }, { filename: 1, 'metadata.path': 1 }) - 再执行删除（驱动里调用
deleteMany）：bucket.deleteMany({ 'metadata.path': { $regex: '^/reports/2024/q1/' } }); - ⚠️ 注意：
deleteMany不会自动清理fs.chunks，但 GridFS Bucket 的deleteMany方法已封装好两集合联动删除——务必用 Bucket 实例的方法，别直接操作fs.files集合。
路径设计一旦开始用，就很难重构；metadata.path 的格式、编码规则、是否带前导斜杠，这些细节在第一批文件上传前就得定死，后期改意味着全量重写 metadata —— 而 GridFS 不支持原子批量更新 metadata。
