gridfs不能直接物理删除文件，因其底层将文件拆分为chunks和files两个集合，需通过在files集合添加isdeleted字段实现逻辑删除，查询、读取、上传、清理均须严格遵循该标记机制。
为什么不能直接删GridFS文件
GridFS底层把文件拆成chunks和files两个集合存储，调用deleteOne()或remove()会真实删除所有分块数据，无法回滚，也不支持软删语义。业务上常需要保留历史版本、审计日志或防止误删，这时候必须绕过物理删除，改用元数据标记。
在files集合中添加isDeleted字段的实操要点
GridFS的files集合（如默认的fs.files）是唯一记录文件元数据的地方，chunks集合不存业务字段。所有逻辑删除操作必须只动files文档：
- 插入新文件时，显式写入
{ isDeleted: false }，不要依赖默认值——MongoDB不会自动补字段 - 执行“删除”时，用
updateOne()更新fs.files中对应_id的文档：db.fs.files.updateOne({ _id: fileId }, { $set: { isDeleted: true, deletedAt: new Date() } }) - 查询文件列表时，必须加
{ isDeleted: { $ne: true } }条件，否则find()或GridFSBucket.find()会返回已“删”文件 - 注意驱动差异：Node.js的
mongodb包里GridFSBucket.find()不自动过滤isDeleted，Java的MongoGridFsTemplate也一样，得手动拼filter
读取文件时如何拦截已逻辑删除的请求
直接调用openDownloadStream()或downloadToStream()不会检查isDeleted，必须前置校验：
- 先用
findOne()查fs.files，确认isDeleted !== true，再继续流式读取 - 封装工具函数时，在
findById()或findByName()里统一加{ isDeleted: { $ne: true } }过滤，避免各处重复写 - 如果用
GridFSBucket.openUploadStream()上传同名文件，旧文件的isDeleted不会自动置为true，需业务层自行处理（比如先查后标删） - 注意TTL索引冲突：若同时用了
expireAfterSeconds，别让deletedAt字段触发自动清理——可单独为非删除文件建TTL索引，或用$and排除已删文档
清理物理存储的时机与风险
逻辑删除只是标记，chunks数据一直占用空间。真正清理要等确认无依赖后手动执行：
- 先删
fs.chunks中对应files_id的块：db.fs.chunks.deleteMany({ files_id: { $in: [ /* 已标删的fileId数组 */ ] } }) - 再删
fs.files中这些文档：db.fs.files.deleteMany({ _id: { $in: [...] }, isDeleted: true }) - 千万别反着来——先删
files会导致chunks变成孤儿数据，且后续无法通过GridFS API定位清理 - 生产环境建议用脚本分批清理，加
limit(1000)和sleep(100)防锁表；清理前备份files_id列表，留作追溯
实际落地时，最易被忽略的是查询入口的统一过滤——哪怕只漏掉一个find()调用，就会暴露已删文件。元数据字段本身简单，但一致性保障全靠代码纪律。
