GridFS 文件删除必须使用 bucket.delete(fileId) 原子操作，否则易产生 fs.files 孤儿文档；手动删 chunks 或业务表ID会导致元数据残留、索引膨胀和磁盘空间无法回收，compact 可整理空间但有阻塞风险。
fs.files 和 fs.chunks 集合里的文档没真正删干净，磁盘空间就不会回收——MongoDB 不会自动释放已删除文档占用的物理空间，更不会因你删了业务表引用就顺手清掉 GridFS 元数据或分块。
fs.files 堆积大量“孤儿”文档
- 常见错误：调用
deleteOne()或remove()只删了业务表里的文件 ID 字段，或手动执行db.fs.chunks.deleteMany({ files_id: ... })，却漏掉db.fs.files.deleteOne({ _id: ... }) -
fs.files文档本身很小（几十字节），但它的索引（尤其是默认{ filename: 1, uploadDate: 1 }）会随数量增长显著拖慢写入、抬高内存缓存压力 - 验证方式：运行
db.fs.files.countDocuments({})和db.fs.chunks.countDocuments({})，若前者远大于后者（比如 2 倍以上），基本就是孤儿元数据在堆积
dropCollection() 或 deleteMany() 后空间不释放
- MongoDB WiredTiger 引擎不会立即归还磁盘空间给操作系统，只会把空间标记为“可重用”
- 即使你删光了
fs.chunks所有文档，db.fs.chunks.stats().size可能仍显示旧值，而db.fs.chunks.stats().storageSize才反映实际磁盘占用 -
compact命令能触发空间整理，但它会阻塞集合读写，且要求副本集主节点执行；私有化部署中常因权限或运维策略被禁用
大量小文件 + 默认 chunkSizeBytes: 255 * 1024 加剧碎片
- 每个文件至少生成一个
fs.chunks文档，哪怕只有 1KB；10 万张头像图 ≈ 10 万个 chunk 文档 - 默认分块大小导致
fs.chunks文档数爆炸，WiredTiger 的页分裂和碎片率上升，缓存效率下降，间接推高整体磁盘占用 - 改大
chunkSizeBytes（如设为1024 * 1024）能减少文档总数，但要注意：MongoDB wire protocol 单包上限约 16MB，驱动内部仍有缓冲开销，盲目设到 4MB 未必带来线性收益
真正该盯住的不是“删没删”，而是“删得干不干净”
- 删文件必须走
bucket.delete(fileId)，这是唯一保证fs.files和fs.chunks同时清理的原子操作 - 如果用了软删除，别只加字段，得在所有读取路径（比如
openDownloadStreamByName()）里显式过滤deletedAt: { $exists: false } - 定期清理不能替代流程管控——上次你手动跑的聚合删孤儿文档，下次上线新功能又绕过 bucket API 直接删 chunks，问题照旧
