GridFS删除文件后磁盘空间不释放，因WiredTiger仅标记空间可复用而不返还OS；需先清理孤儿chunk，再于primary节点依次compact fs.chunks和fs.files，或通过mongodump/mongorestore重建。
GridFS 删除文件后磁盘空间不释放，不是删错了，而是 WiredTiger 引擎根本没打算“还给操作系统”——它只把空间标记为可复用，后续写入会优先填进去，但 df -h 看到的磁盘占用几乎不变。
为什么 delete() 或 bucket.delete() 后空间还是满的
调用 bucket.delete(fileId) 确实会原子性清理 fs.files 和 fs.chunks 两个集合里的对应文档，但这只是逻辑删除。WiredTiger 不会立即收缩底层 .wt 数据文件，也不会触发文件系统级的空间归还。即使你确认 db.fs.files.countDocuments() 和 db.fs.chunks.countDocuments() 都已归零，storageSize 可能仍卡在高位。
- 这是正常行为，不是 bug；MongoDB 从不承诺“删即释放”
-
dropCollection("fs.chunks")同样无效：集合被清空，但 .wt 文件尺寸照旧 - 云托管服务（如 Atlas）还可能叠加快照、备份延迟，让释放更不可见
compact 命令为什么有时没效果
db.runCommand({compact: "fs.chunks"}) 要生效，必须同时满足三个硬前提：连的是副本集 primary 节点、fs.chunks 里没有孤儿块、且先 compact fs.chunks 再 compact fs.files。漏掉任一，命令就等于白跑。
- 孤儿 chunk 是最大干扰项：执行
db.fs.chunks.deleteMany({"files_id": {$nin: db.fs.files.distinct("_id")}})清理前，compact对它们完全无视 - 在
secondary上执行compact会静默失败，无报错但无效果 - compact 过程中需额外磁盘空间 ≈ 当前
fs.chunksstorageSize× 1.2；空间不足时命令卡住或中断
真正能回收空间的实操路径只有两条
一条是引擎内整理，一条是数据重建。没有中间选项。
- 路径一（推荐先试）：清理孤儿 →
compactfs.chunks→compactfs.files，全程在primary执行，避开高峰 - 路径二（终极方案）：停写 →
mongodump导出非 GridFS 数据 + 保留必要元数据 →dropDatabase→mongorestore，适合磁盘余量紧张或 compact 多次无效时 - 别碰
repairDatabase：MongoDB 7.0+ 已弃用，且修复过程高风险、长阻塞、需双倍磁盘空间
最容易被忽略的其实是时间差：你删完文件、跑完 compact、甚至等了半小时，df -h 还是不动——这不意味着失败，而是 WiredTiger 的页重写还没完成，或者 OS 层缓存未刷新。真要验证是否生效，得看 db.fs.chunks.stats().storageSize 是否下降，而不是盯着磁盘百分比。
