uploadDate 字段存在于 GridFS 底层的 fs.files 集合中，类型为 Date，需直接查询该集合或通过 GridFSBucket.find({}) 显式获取；删除文件必须用 bucket.delete() 以避免孤立 chunk。
GridFS 的 uploadDate 字段在哪查？
GridFS 本身不直接暴露文件元数据为普通集合字段，uploadDate 实际存在底层 fs.files 集合中，类型是 Date。你不能对 fs.chunks 查询这个时间，也不能用 GridFSBucket.find() 默认返回的文档直接点出 uploadDate —— 它只在 fs.files 文档里完整存在。
用 find() 直接查 fs.files 集合最简单
绕过 GridFS 封装，直连 fs.files 集合做时间范围查询，是最可控、最高效的方式：
- 连接数据库后，获取
db.collection('fs.files')（不是db.fs.files，那是旧 shell 语法） -
uploadDate是标准Date类型，可直接用$lt/$gt比较 - 注意时区：MongoDB 存的是 UTC 时间，你的本地时间需转换后再构造
Date对象 - 示例（Node.js + MongoDB Driver）：
const filesCollection = db.collection('fs.files');
const cutoff = new Date(Date.now() - 30 * 24 * 60 * 60 * 1000); // 30天前的UTC时间
const oldFiles = await filesCollection.find({
uploadDate: { $lt: cutoff }
}).toArray();
用 GridFSBucket.find() 也能查，但有陷阱
GridFSBucket.find() 底层其实也是查 fs.files，但它返回的文档是简化版，uploadDate 字段默认存在，但部分驱动版本（如早期 v3.x）可能因投影控制丢失该字段。
- 必须显式传空过滤对象
{}，不能传null或省略，否则某些驱动会报错 - 确保没设置
projection过滤掉uploadDate（比如写了{ projection: { filename: 1 } }就会丢掉它） - 如果要加时间条件，必须写进第一个参数里：
bucket.find({ uploadDate: { $lt: cutoff } }) - 性能上无差异，但语义更“GridFS”，适合后续要调用
openDownloadStream()的场景
删旧文件别只删 fs.files，得用 delete()
手动 deleteOne() fs.files 文档会导致 fs.chunks 孤立，磁盘空间不会释放。
- 必须用
GridFSBucket.delete(new ObjectId(fileId))，它自动清理两集合关联数据 - 所以先查
fs.files拿_id，再逐个调delete()；不要用fs.files.deleteMany() - 批量删除建议加
limit(100)分批，避免长事务或内存溢出 - 注意：MongoDB 5.0+ 支持
deleteMany()配合GridFSBucket，但 driver 实现仍不统一，稳妥起见仍推荐单删
实际操作中最容易卡在时区转换和孤立 chunk 上——uploadDate 看似简单，但删错一步，清理就变成数据损坏。
