只有官方驱动调用delete()方法才能真正删干净，直接删fs.files文档不会自动清理fs.chunks，导致孤儿块堆积和磁盘空间不释放；mongosh、绕过Bucket的删除及PHP传错参数均会失效；uploadDate查询需确保类型匹配且使用$lt；删后空间不释放是WiredTiger正常行为，需compact或dump/restore回收。
用官方驱动的 delete() 方法才真正删干净
直接删 fs.files 集合里的文档，fs.chunks 不会自动清理——这是线上磁盘空间不释放的头号原因。只有官方驱动（Node.js v4+、PHP v1.x、Go 官方 driver）调用封装好的 delete() 才会先删 fs.chunks、再删 fs.files，保证原子性和数据一致性。
常见错误操作包括：
- 在 mongosh 里执行 db.fs.files.deleteMany({}) —— 只删元数据，fs.chunks 全部变孤儿块
- Node.js 中绕过 GridFSBucket，用 bucket.s.db.collection("fs.files").deleteMany(...) —— 同样跳过级联逻辑
- PHP 传字符串文件名给 MongoDB\GridFS\Bucket::delete() —— 它只认 ObjectId，传错就静默失败或报 FileNotFoundException
uploadDate 查询过期文件必须类型匹配
uploadDate 字段是 BSON Date 类型，不是字符串也不是毫秒数。如果业务写入时用了 new Date().toISOString() 或 Date.now()，查询条件就会失效。
实操前务必验证真实值格式：
- 运行 db.fs.files.findOne({ uploadDate: { $exists: true } }, { uploadDate: 1 })
- 计算截止时间用 new Date(Date.now() - 30 * 24 * 60 * 60 * 1000)，别用 setDate()（受本地时区干扰）
- 查询语句必须是 {"uploadDate": { "$lt": cutoffDate }}，漏掉 $lt 就查不到
- 若有迁移补填的旧数据，建议加字段如 "metadata.migrated": false 做双重校验
删完磁盘空间没变化？不是失败，是 MongoDB 的正常行为
即使 fs.files 和 fs.chunks 文档都清空了，MongoDB 也不会立刻归还磁盘空间给操作系统。这是 WiredTiger 存储引擎的设计：它会复用已释放的空间，而不是收缩数据文件。
如果确实需要释放物理空间：
- 执行 db.runCommand({ compact: "fs.chunks" }) 和 db.runCommand({ compact: "fs.files" })（需停写、且只对 MMAPv1 有效）
- 更稳妥的做法是 mongodump + mongorestore 全量重建数据库
- 或者启用 storage.wiredTiger.engineConfig.configString = "cache_size=..." 并配合定期 db.fsyncLock()（生产环境慎用）
批量删大量文件时注意性能和锁竞争
GridFS 删除本质是两阶段操作（删 chunks → 删 files），并发高时容易触发写锁争用，尤其在分片集群上可能拖慢其他写请求。
建议：
- 每次删除控制在 100–500 个文件以内，用 bulkWrite 或循环 + await 分批
- 避免在业务高峰执行，优先安排在低峰期或维护窗口
- 监控 db.currentOp({ "secs_running": { "$gt": 5 } })，及时发现长事务阻塞
- 如果只是清理历史归档，考虑改用 TTL 索引替代主动删除（但 fs.files 不支持 TTL，需自行实现定时任务）
