GridFS不支持原生TTL，需在fs.files建TTL索引并显式设置expiresAt字段，同时配对清理fs.chunks以避免孤儿块；必须手动创建files_id索引并验证清理效果。
GridFS本身不支持TTL，必须手动管理files集合的TTL索引
GridFS是MongoDB的文件存储规范，由fs.files和fs.chunks两个集合组成。关键点在于：fs.chunks不能建TTL索引（MongoDB明确禁止），而fs.files可以——但TTL只清理元数据文档，不会自动删除关联的fs.chunks数据。如果不干预，就会留下“孤儿块”，持续占用磁盘空间。
实操建议：
- 在
fs.files集合上为uploadDate或自定义字段（如expiresAt）创建TTL索引，例如：db.fs.files.createIndex({ "expiresAt": 1 }, { expireAfterSeconds: 0 }) - 务必确保写入
fs.files时显式设置expiresAt字段（类型为Date），不要依赖uploadDate——因为上传时间 ≠ 过期时间，业务语义更清晰且可控 - TTL后台线程每60秒扫描一次，延迟不可忽略；对时效性要求高的场景，不能只靠它做唯一保障
必须配对清理fs.chunks，否则产生存储泄漏
TTL索引删除fs.files文档后，对应fs.chunks里的files_id就变成悬空引用。MongoDB不会自动级联删除，这些chunk会永久滞留。
安全做法是用定时任务（如cron + Node.js脚本或MongoDB Atlas的Scheduled Triggers）执行两阶段清理：
- 先查出已被TTL删除的
files_id（通过变更流监听fs.files的delete事件最准；若无变更流，可用db.fs.files.find({ _id: { $nin: [...] } })反查，但性能差） - 再根据这些
files_id批量删除fs.chunks中对应文档：db.fs.chunks.deleteMany({ files_id: { $in: [/* id array */] }}) - 生产环境强烈建议加
explain("executionStats")验证files_id字段是否有索引——默认没有，必须手动创建：db.fs.chunks.createIndex({ "files_id": 1 })
驱动层写入时需显式注入expiresAt，不能靠服务端默认
所有官方驱动（Node.js、Python PyMongo、Java等）的GridFSBucket.uploadFromStream()或类似方法，均不会自动写入过期字段。你必须在options.metadata或options顶层传入expiresAt。
以Node.js为例：
const bucket = new GridFSBucket(db);
await bucket.uploadFromStream(
"report.pdf",
readableStream,
{
metadata: {
expiresAt: new Date(Date.now() + 24 * 60 * 60 * 1000)
}
}
);
注意：
-
expiresAt必须是Date对象，字符串或毫秒数会被忽略 - 如果用
uploadFromStream的options直接传expiresAt（某些驱动支持），优先用这种方式——它会写入fs.files根层级，比塞进metadata更利于索引查询 - 别在应用层用
setTimeout模拟过期：进程重启即失效，且无法跨实例同步
监控和验证TTL是否生效，重点看fs.chunks体积变化
TTL是否真起作用，不能只查fs.files数量下降。真正危险的是fs.chunks持续膨胀却无人察觉。
日常检查项：
- 用
db.fs.files.stats()和db.fs.chunks.stats()对比文档数与存储大小，若后者下降缓慢甚至不降，说明chunk未清理 - 查最近一小时被TTL删除的文件ID：
db.fs.files.find({ expiresAt: { $lt: new Date() } }).limit(5).forEach(printjson)——若返回空，可能是索引没生效或时间字段写错 - 在
mongod日志中搜索Expired关键字（需开启verbosity），确认TTL线程是否在运行
最易被忽略的是：TTL索引创建后，已有文档不会自动获得expiresAt值。老文件永远不过期，必须用updateMany补全，或在迁移时重写。
