gridfs不支持逻辑删除，需应用层在fs.files中添加isdeleted字段并统一查询过滤；必须为该字段建索引，禁用直接删集合操作，所有读取和聚合均需显式排除已标记项。
GridFS 本身不支持逻辑删除
GridFS 是 MongoDB 的文件存储规范，底层只用两个集合（fs.files 和 fs.chunks）存元数据和分块数据，它没有内置的 deleted 标志字段或软删机制。所谓“逻辑删除”，必须由应用层自行设计和维护。
在 fs.files 中添加 isDeleted 字段并查询过滤
这是最常用、也最可控的做法：不删文档，只加标记，后续所有读取操作都显式排除已标记项。
- 插入文件时，默认设
isDeleted: false；删除时只更新该字段为true - 所有
find()、findOne()查询必须带上{ isDeleted: { $ne: true } }条件，否则会漏掉逻辑删的干扰 - 注意
GridFSBucket.openDownloadStream()不接受查询条件，必须先用find()拿到合法_id，再传给流方法 - 别忘了在
fs.files上为isDeleted建索引（尤其当文件量大时），否则全表扫描代价高
避免误删 fs.chunks 或留下孤立块
手动删 fs.files 文档但没清理对应 fs.chunks，会导致 chunks 积压、磁盘持续增长，且无法通过 GridFS 工具自动回收。
- 永远不要直接删
fs.chunks中的文档——除非你完整实现了块引用计数和垃圾回收逻辑 - 如果真要物理清理，必须用
bucket.delete()（它会同步删 files + chunks），但这是硬删，不是逻辑删 - 某些旧版驱动或自定义封装可能绕过
bucket.delete()直接操作集合，这种写法在加了isDeleted后极易出错
查询性能和聚合场景下的陷阱
加了 isDeleted 后，所有涉及文件列表、统计、聚合的操作都容易漏条件，尤其是和用户权限、时间范围混用时。
-
countDocuments({ filename: "xxx" })会把已逻辑删的也算进去，得写成{ filename: "xxx", isDeleted: { $ne: true } } - 用
aggregate()做文件大小汇总？第一阶段就得$match: { isDeleted: { $ne: true } }，否则结果虚高 - 如果业务要求“回收站”功能，建议单独加
deletedAt时间戳字段，而不是只靠布尔值，方便按时间恢复或自动清理
真正麻烦的不是加个字段，而是让整个代码库所有访问 GridFS 的地方都意识到：这个“文件存在”是有状态的，不是非黑即白。
