必须先删 chunks 再删 files，否则 chunks 变孤儿块；deleteOne() 仅对 files 有效，需先查 fileId 再删 chunks 和 files；推荐用 GridFSBucket.delete() 保障原子性。
直接用 deleteOne() 删除 GridFS 文件会失败
GridFS 不是普通集合，它把文件拆成 chunks 和 files 两个集合存储。只删 files 文档，chunks 还在，磁盘空间不会释放——这是最常踩的坑。
正确做法必须同时清理两部分，且顺序不能错：先删 chunks，再删 files；否则 chunks 可能变成“孤儿块”，后续无法识别和回收。
-
deleteOne()对files集合有效，但对chunks集合无效——因为chunks的_id是随机生成的，不对应文件名或filename - 真正可定位的是
files集合里的_id（即fileId），它被用作chunks中的files_id字段值 - 所以得先查出目标文件的
_id，再用它去删chunks和files
按文件名删除：先查 _id，再批量删 chunks + files
文件名不是唯一键，可能有重名；但通常业务里靠 filename + uploadDate 或其他元字段组合定位更稳。
实操建议分三步走：
- 从
fs.files查出匹配的文档，拿到_id（注意：这是ObjectId类型，不是字符串） - 用该
_id去fs.chunks删除所有files_id匹配的块：db.fs.chunks.deleteMany({ files_id: fileId }) - 最后删
fs.files中对应文档：db.fs.files.deleteOne({ _id: fileId })
示例（Shell）：
const fileId = db.fs.files.findOne({ filename: "report.pdf" })._id;
db.fs.chunks.deleteMany({ files_id: fileId });
db.fs.files.deleteOne({ _id: fileId });
用 GridFSBucket API 删除更安全（Node.js 场景）
手写两阶段删除容易漏掉异常处理，比如删 chunks 成功但删 files 失败，就会留下脏数据。官方 GridFSBucket 封装了原子性保障。
关键点：
-
delete()方法只接受ObjectId，不是文件名——必须先用find()或findOne()拿到_id - 它内部自动执行
chunks→files的顺序删除，并带事务回滚（MongoDB 4.0+ 副本集/分片集群支持） - 如果没找到对应
_id，delete()不报错，只是静默跳过
示例（Node.js）：
const bucket = new GridFSBucket(db, { bucketName: 'fs' });
const file = await db.collection('fs.files').findOne({ filename: 'log.zip' });
if (file) await bucket.delete(file._id);
误删后恢复困难，操作前务必确认 _id 和影响范围
GridFS 没有回收站，delete 是不可逆的。生产环境最常忽略的是：同一文件名可能对应多个版本，findOne() 只取最新上传的那个——而你可能想删的是旧版。
建议动作：
- 删之前加
.project({ _id: 1, filename: 1, uploadDate: 1, length: 1 })确认目标是否准确 - 对重要文件，先用
find()查全量匹配项，人工核对uploadDate或自定义元字段（如version） - 别依赖
filename做唯一判断；如果业务需要精确控制，应在上传时写入唯一标识到metadata字段
真正麻烦的不是怎么删，而是删完才发现删错了——因为 chunks 数据散落在不同 chunk 大小的文档里，没法像普通集合那样快速 scan 或 restore。
