应直接对 fs.files 集合调用 deletemany() 删除用户文件，驱动自动级联清理 fs.chunks；需确保 metadata 字段结构统一、类型匹配、命名规范，并先用 find() 验证范围，避免误删。
用 deleteMany() 配合 files 集合的 metadata 字段删除
GridFS 不是单个集合，而是由 fs.files 和 fs.chunks 两个集合协同工作。真正存文件元信息（比如上传者 ID）的是 fs.files，metadata 字段就在这里。要删某个用户的所有文件，必须先在 fs.files 中定位，再让 GridFS 自动清理对应 fs.chunks 数据——不能手动删 chunks，否则会残留垃圾。
实操时直接对 fs.files 调用 deleteMany() 即可，驱动会自动级联清理：
db.fs.files.deleteMany({ "metadata.userId": "user_123" })
注意：这个操作不可逆，且不会触发任何钩子或监听器。
确保 metadata 字段写入时结构一致，否则查不到
很多人删不掉，根本原因是写入时没统一格式。比如有的写成 { userId: "abc" }，有的写成 { user: { id: "abc" } }，还有的把 ID 当数字存。查询前务必确认实际存储结构：
- 用
db.fs.files.findOne({ "metadata.userId": { $exists: true } })检查真实字段路径 - 如果
userId是字符串类型，但数据库里存的是数字，"metadata.userId": 123才能匹配，"metadata.userId": "123"查不到 - 避免在
metadata里混用大小写，如userId和userid被视为不同字段
删除前建议先用 find() 验证范围，尤其在线上环境
直接 deleteMany() 风险高，尤其当 metadata 字段被多业务共用时。先确认命中的文件是否真的都属于该用户：
db.fs.files.find({ "metadata.userId": "user_123" }, { filename: 1, uploadDate: 1, length: 1 }).limit(5)
重点关注 filename 和 uploadDate 是否符合预期。如果返回为空，检查是否用了错误的字段名或值类型；如果返回过多，说明 metadata 可能被其他逻辑复用，需加额外条件（如 "metadata.uploadSource": "web"）缩小范围。
Node.js 驱动中用 GridFSBucket 无法直接按 metadata 删除
GridFSBucket API（如 bucket.delete()）只接受 _id，不支持 query 删除。想用 metadata 过滤，必须绕过 bucket，直接操作底层集合：
- 获取原始 db 实例：
const db = bucket.s.db（MongoDB Node.js 驱动 v4+） - 然后操作
db.collection("fs.files")，不是bucket - 别试图用
bucket.find({ "metadata.userId": ... })——它不支持在 metadata 上做嵌套查询，会静默忽略条件
这一步最容易卡住：文档里没明说 bucket.find() 对 metadata 的限制，但实际就是不生效。
真正麻烦的不是语法，而是 metadata 的写入源头是否可控、字段命名是否全局统一、以及有没有其他服务也在往同一个 GridFS bucket 里写文件。删之前，最好 grep 一下所有代码里 gridFSBucket.openUploadStream() 的调用点，确认 metadata 的构造逻辑。漏掉一个分支，就可能误删或漏删。
