直接查db.fs.files集合最可靠，因GridFS元数据（filename、length、uploadDate、md5、metadata）全在此，fs.chunks仅存二进制分块；GridFS.find()封装不一致易导致条件丢失或空结果，且默认不支持链式操作，需显式建索引（如{length:1}）提升查询性能。
db.fs.files 集合，别绕路 —— GridFS 的元数据（包括 filename、length、uploadDate、md5、metadata）全在 fs.files 里，fs.chunks 只存二进制分块，不带任何元信息。
为什么不能用 GridFS.find() 封装方法做条件查询？
不同驱动对 gridfs.GridFS.find()（如 PyMongo）的实现不一致：旧版会自动包装查询条件，新版倾向透传但行为未完全标准化；它底层仍查 fs.files，但可能加额外过滤或忽略某些字段。一旦你写 {"length": {"$gte": 1024}}，封装层可能误判为无效键、静默丢弃，或返回空结果。
- 显式操作
db["fs.files"]（PyMongo）或db.fs.files（shell）最可靠 - 自定义存储桶（如
bucketName: "media"）时，集合名变成media.files，不是fs.files—— 必须按实际前缀拼接 -
GridFS.find()默认只返回游标，不支持链式.sort()或.limit()，得转成集合操作才好控制
db.fs.files 查询常见字段和类型
length 是文件总字节数，类型为 NumberLong（64位整型）或 int（取决于 MongoDB 版本和写入驱动），比较时直接用数字即可，无需转类型。
-
filename：字符串，支持正则匹配，如{"filename": {"$regex": "\.pdf$", "$options": "i"}} -
uploadDate：ISODate 类型，可用$gte/$lt做时间范围，如{"uploadDate": {"$gte": ISODate("2026-01-01"), "$lt": ISODate("2026-07-01")}} -
metadata：嵌套对象，可按路径查，如{"metadata.tag": "report"}（前提是写入时存了该字段） -
md5：字符串，小写 32 位 hex，可用于去重或校验，如{"md5": "d41d8cd98f00b204e9800998ecf8427e"}
容易被忽略的性能与索引问题
默认 GridFS 会在 fs.files 上建两个索引：{ "_id": 1 } 和 { "filename": 1, "uploadDate": 1 }。但如果你常按 length 或 metadata.tag 查询，这些字段没索引，大数据量下会全表扫描。
- 加索引命令示例：
db.fs.files.createIndex({ "length": 1 })或db.fs.files.createIndex({ "metadata.tag": 1 }) - 索引创建后需等后台构建完成，期间查询仍慢；生产环境建议在低峰期执行
- 自定义存储桶（如
"media"）必须在对应集合上建索引：db["media.files"].createIndex(...)，不会自动继承fs的索引
fs.files（或你的桶名 + .files），用原生集合语法查，别信封装层的“便利性”。字段名、类型、索引——这三个点漏掉任何一个，都可能让查询变慢、结果为空或行为不可控。 
