GridFS删除文件不会立即释放磁盘空间，仅逻辑删除fs.files和fs.chunks文档，WiredTiger标记空间为可复用但不返还OS；需compact命令或dump/restore重建才能真正释放。
GridFS 删除文件 ≠ 磁盘空间立即释放
不会。删除 GridFS 文件（比如调用 delete 或 remove）只是从 fs.files 和 fs.chunks 两个集合里删掉对应文档，WiredTiger 引擎并不会立刻把底层磁盘块还给操作系统——空出来的空间会被标记为“可复用”，后续插入新 chunk 时优先填这里，但磁盘占用数字基本不变。
为什么 dropCollection 也救不了磁盘？
因为 GridFS 的数据分散在两个集合：fs.files 存元数据，fs.chunks 存二进制分片。即使你手动 db.fs.files.drop() 和 db.fs.chunks.drop()，WiredTiger 仍保留已分配的数据文件（.wt 文件），只清空逻辑内容；除非整个数据库被 dropDatabase，否则磁盘空间不退。
- WiredTiger 默认启用
useJournal=true和cache_size管理，回收依赖后台 compact 或文件重写 - GridFS 没有“truncate”语义，它本质就是普通文档操作，不触发底层空间收缩
- 如果你用的是 MongoDB Atlas 或云托管服务，底层存储卷可能还带快照/备份机制，进一步延迟可见释放
真正释放空间的实操路径
必须走 WiredTiger 原生命令或重建流程，没有捷径：
-
db.runCommand({compact: "fs.chunks"})—— 推荐先 compactfs.chunks（它占空间大），再 compactfs.files - 执行前确保有足够内存和磁盘临时空间（compact 会重写文件，期间磁盘占用可能短暂翻倍）
- 该命令阻塞写入，建议在低峰期执行；可用
db.currentOp({secs_running: {$gt: 10}})监控进度 - 如果 compact 失败或效果有限，终极方案是
mongodump+mongorestore全量重建库（注意：需停写、耗时长、要额外空间）
容易被忽略的细节
很多人以为删了 GridFS 文件就等于“清空附件”，结果几周后发现磁盘还是满的——问题常出在两处：
- 没意识到
fs.chunks集合默认无 TTL 索引，历史碎片永远躺着等 compact - 误用
db.fs.files.remove({})却忘了同步清理fs.chunks，导致 chunks 成为“孤儿文档”，compact 也扫不到 - 在副本集上执行 compact，必须连到 primary，且不能在维护窗口外随意触发（可能影响 oplog 压力）
真正的释放，从来不是删动作本身，而是你有没有让引擎重新整理物理页。
