gridfs 的 contenttype 字段需手动存入 metadata，查询须用 metadata.contenttype 并建索引；未索引会导致全表扫描，应执行 db.fs.files.createindex({"metadata.contenttype": 1})。
GridFS 文件类型字段到底存哪儿？
GridFS 本身不强制要求存储文件类型，contentType 字段不是 MongoDB 内置字段，而是靠你写入时手动塞进 metadata 或顶级字段里的。常见错误是直接查 contentType 却没写进去，结果永远查不到——先确认你当初用 put() 或 upload_from_stream() 时有没有显式传入这个键。
实际存储结构通常是这样：
{ "_id": ObjectId("..."), "filename": "report.pdf", "length": 123456, "chunkSize": 261120, "uploadDate": ..., "metadata": { "contentType": "application/pdf" } }
所以检索必须走 metadata.contentType，而不是平级的 contentType。
用 find() 查指定 contentType 的文件，但速度慢？
默认情况下 metadata.contentType 没索引，每次查询都要扫整个 fs.files 集合。尤其当文件数过万，延迟明显上升。
解决办法只有一条：手动建索引。
- 在 MongoDB Shell 中运行：
db.fs.files.createIndex({ "metadata.contentType": 1 }) - 如果还常按时间范围查，可以复合索引：
db.fs.files.createIndex({ "metadata.contentType": 1, "uploadDate": -1 }) - 注意：索引建在
fs.files上，不是fs.chunks；后者只存二进制分块，不含元信息
Python PyMongo 示例：安全取 PDF 文件流
别用 find_one() 后再手动拼 _id 去 get()，容易漏掉多文件同名或 metadata 缺失的情况。
推荐写法是直接用 gridfs.GridFSBucket（比旧版 GridFS 类更明确）：
from gridfs import GridFSBucket
bucket = GridFSBucket(db)
cursor = db.fs.files.find({ "metadata.contentType": "application/pdf" }).limit(10)
for doc in cursor:
file_id = doc["_id"]
try:
grid_out = bucket.open_download_stream(file_id)
# 处理 stream，比如读前 1KB 判断是否真为 PDF
except FileNotFoundError:
continue # 文件 chunk 损坏或已删，跳过
关键点：
- 先查
fs.files得到_id，再用open_download_stream()拉流，避免一次性 load 全量内容 - 加
try/except捕获FileNotFoundError，因为fs.files和fs.chunks不是原子操作，可能有残留元数据 - 如果只要文件名和大小，别调
open_download_stream()，查fs.files就够了
为什么用正则查 “image/*” 会变慢甚至超时？
metadata.contentType: { $regex: "^image/" } 这种写法无法利用普通 B-tree 索引，MongoDB 只能全表扫描。即使建了索引也白搭。
真正可行的替代方案只有两个：
- 写入时归一化类型：把
"image/jpeg"、"image/png"统一存成metadata.mediaType: "image"，然后查{ "mediaType": "image" }—— 索引完全生效 - 如果必须保留原始值，且类型枚举有限，改用
$in：{ "metadata.contentType": { $in: ["image/jpeg", "image/png", "image/gif"] } }
没有“模糊匹配又快”的银弹。类型字段设计阶段就要想好查询模式，后期补救成本很高。
最常被忽略的是：GridFS 查询性能瓶颈几乎全出在 fs.files 的索引缺失或误用上，而不是读取逻辑本身。检查一遍 db.fs.files.getIndexes()，比优化 Python 循环有用得多。
