GridFS不支持文件自动过期，TTL索引无法级联删除fs.chunks，必须通过定时任务先查过期fs.files._id，再批量删除对应fs.chunks，最后删除fs.files，确保数据一致性。
GridFS本身不支持文件自动过期，files集合里的uploadDate不能直接触发TTL索引
MongoDB的TTL索引只作用于文档自身的字段，而GridFS把元数据存在fs.files集合、二进制块存在fs.chunks集合。即使你在fs.files.uploadDate上建了TTL索引，MongoDB也不会自动删对应的fs.chunks文档——这会导致数据不一致和存储泄漏。
常见错误现象是：TTL索引看似生效，fs.files里文档被删了，但fs.chunks还留着，db.fs.chunks.count()持续上涨，磁盘空间只增不减。
- 必须手动关联删除
fs.chunks，不能依赖TTL自动级联 -
fs.files._id是fs.chunks.files_id的唯一关联字段，这是清理的关键线索 - 不要尝试在
fs.chunks上建TTL索引——它没有时间字段，也没业务意义
用定期作业+原子性查询删除实现安全清理
核心思路是：先查出所有过期的fs.files文档ID，再用$in批量删fs.chunks，最后删fs.files。顺序不能反，否则 chunks 成为孤儿。
推荐用MongoDB 6.0+的deleteMany配合find分批处理，避免单次操作过大阻塞：
db.fs.files.deleteMany({
uploadDate: { $lt: new Date(Date.now() - 7 * 24 * 60 * 60 * 1000) }
})但这只是半步——你还得同步删chunks。完整脚本逻辑如下：
- 用
find获取过期fs.files._id（建议每次最多1000个，加.limit(1000)） - 用这些ID构造
{ files_id: { $in: [...] } }条件，调db.fs.chunks.deleteMany() - 确认
deletedCount匹配后，再执行db.fs.files.deleteMany() - 把这段逻辑封装成定时任务（如Linux cron调用
mongosh脚本，或Node.js中用node-schedule）
在应用层写入时主动标记生命周期更可控
硬编码过期时间不如让业务决定。可以在fs.files的metadata字段里存自定义过期时间，比如{ "expiresAt": ISODate("2025-04-10T00:00:00Z") }。这样清理条件就变成：
db.fs.files.deleteMany({
"metadata.expiresAt": { $lt: new Date() }
})好处很明显：
- 不同文件可设不同过期策略（上传日志保留1天，用户头像保留1年）
- 支持运行时动态更新：
db.fs.files.updateOne({ _id: xxx }, { $set: { "metadata.expiresAt": ... } }) - 避免误删：TTL索引基于
uploadDate是“创建即过期”，而expiresAt是“按需过期” - 注意：
metadata字段要确保写入时存在，驱动默认不自动创建空对象
驱动层封装清理逻辑时别忽略游标超时和连接中断
如果用Python PyMongo或Node.js MongoDB Driver做自动清理，容易在大文件集上遇到Cursor not found或网络断连。关键点：
- 查
fs.files时加no_cursor_timeout=True（PyMongo）或cursorTimeoutMS: 0（Node.js），防止游标过期 - 删除操作必须用
with_transaction（PyMongo）或session.withTransaction()（Node.js）包裹，保证chunks和files删除的原子性 - 每次批量删完检查
deletedCount，不为0才继续下一批；为0说明没数据了，退出循环 - 别在
fs.files上建太多索引——{ uploadDate: 1 }或{ "metadata.expiresAt": 1 }够用，多余索引拖慢删除速度
真正麻烦的不是写几行删除代码，而是验证chunks是否真被清干净。上线前务必用db.fs.chunks.find({ files_id: ObjectId("...") })抽查已删文件ID，确认返回空结果。
