不能直接删 fs.files 自动清理 fs.chunks，仅官方驱动调用 deletemany()/deleteone() 时才级联清理；mongosh 直接删仅删元数据，chunks 成孤儿块。
直接删 fs.files 就能自动清理 fs.chunks 吗？
能，但只在用 deleteMany() 或 deleteOne() 操作 fs.files 集合时成立——前提是使用官方驱动（如 Node.js v4+、PHP v1.x、Go 官方 driver），且未手动绕过 GridFS Bucket 层。驱动检测到对 fs.files 的删除操作后，会自动触发对对应 fs.chunks 的级联清理。
但注意：mongosh 或 mongo shell 直接执行 db.fs.files.deleteMany(...) 不触发任何自动清理；它只是删掉元数据文档，fs.chunks 会全部残留成孤儿块。这是线上误删后磁盘不释放的最常见原因。
- Node.js 中必须通过
bucket.s.db.collection("fs.files")获取原始 collection 实例再删，不能用bucket.find()过滤后删 ——bucket.find()不支持嵌套 metadata 查询，条件会被静默忽略 - PHP 中
MongoDB\GridFS\Bucket::delete()只接受$id（即ObjectId），传字符串文件名会报错或静默失败 - Go 驱动默认不自动级联，需显式调用
bucket.Delete(ctx, id)，底层才保证 chunks → files 顺序清理
uploadDate 字段能直接用来删过期文件吗？
可以，但必须确认字段类型和时区一致性。MongoDB 存储的 uploadDate 是 Date 类型，不是字符串或时间戳数字。如果应用写入时用了 new Date().toISOString() 或毫秒数，查询就会失效。
实操前先验证：
- 运行
db.fs.files.findOne({ uploadDate: { $exists: true } }, { uploadDate: 1 })看真实值格式 - 计算截止时间要用
new Date(Date.now() - 30 * 24 * 60 * 60 * 1000)，别用setDate()（会受本地时区影响） - 查询语句必须是
{"uploadDate": { "$lt": cutoffDate }}，不能漏掉$lt操作符 - 如果业务里有手动改过
uploadDate（比如迁移旧数据时补填），要额外加校验字段，例如"metadata.migrated": false
删完发现磁盘空间没释放，怎么办？
MongoDB 不会立即回收磁盘空间，即使 fs.chunks 和 fs.files 文档都已清空。这是正常行为，但容易被当成“删失败”。
真正释放空间需两步：
- 先运行
db.runCommand({ compact: "fs.chunks" })和db.runCommand({ compact: "fs.files" })（仅支持 WiredTiger 引擎，且需管理员权限） - 如果集群启用了副本集，compact 必须在主节点执行；分片集群需对每个 shard 单独 compact
- 更稳妥的做法是定期执行
db.fs.chunks.validate()和db.fs.files.validate()，检查是否有 orphaned chunks —— 若返回"orphanedCount": > 0，说明之前删操作没走对路径，得手动清理：db.fs.chunks.deleteMany({ files_id: { $nin: db.fs.files.distinct("_id") } })
按业务维度批量删（比如用户 ID、项目 ID）为什么总查不到？
根本原因几乎都是 metadata 写入不规范：字段名大小写混用、嵌套层级不一致、类型错乱（字符串当数字存）、甚至压根没写进 metadata 而是平铺在 fs.files 根层级。
排查和修复步骤：
- 用
db.fs.files.findOne({ "metadata.userId": { $exists: true } })确认字段真实路径；如果返回 null，试试"userId"、"user_id"、"metadata.user.id" - 用
db.fs.files.aggregate([ { $match: { "metadata.userId": { $exists: true } } }, { $group: { _id: { type: { $type: "$metadata.userId" }, len: { $strLenCP: "$metadata.userId" } } } } ])查看实际存储类型和长度分布 - 写入端必须统一用
bucket.uploadFromStream(filename, stream, { metadata: { userId: "u_abc" } })，禁止直接拼fs.files插入 - 线上清理前，永远先跑
db.fs.files.find({ "metadata.userId": "u_abc" }, { filename: 1, uploadDate: 1 }).limit(3)看结果是否符合预期
metadata 字段一旦写歪，后期只能靠全量扫描修复，没有捷径。批量删的本质不是命令问题，而是数据契约是否被所有写入端严格遵守。
