GridFS 不自动写入 contentType 字段，必须手动存入 metadata；查询前需创建索引 db.fs.files.createIndex({"metadata.contentType": 1})，且不同驱动语法不同，如 Spring Data 需用 "metadata.contentType"，Node.js 驱动同理，大小写敏感，旧驱动可能扁平化字段。
为什么直接查 contentType 会查不到文件
GridFS 不会在 fs.files 文档里自动写入 contentType 字段——它只存在于你手动塞进 metadata 对象里的内容。如果你上传时没显式设置 metadata: { contentType: "image/png" }，那这个字段压根不存在，{ "metadata.contentType": "image/png" } 查询永远返回空。
查询前必须确保索引已建
即使 metadata.contentType 存在，没建索引也会触发全集合扫描，尤其当 fs.files 有上万条记录时，一次查询可能耗时数秒甚至超时。
- 执行命令：
db.fs.files.createIndex({"metadata.contentType": 1}) - 确认索引生效：
db.fs.files.getIndexes()中能看到该条目 - 如果用的是自定义 bucket（比如
mybucket），索引要建在mybucket.files上，不是fs.files
不同驱动的写法差异：Java Spring Boot vs Node.js 原生驱动
同一语义的查询，在不同客户端写法不同，错一个点就查不到。
- Spring Data MongoDB（
GridFsTemplate）：
用Query.query(Criteria.where("metadata.contentType").is("application/pdf"))，注意字段名带metadata.前缀 - Node.js 驱动（
mongodb@6.x）：bucket.find({ "metadata.contentType": "application/pdf" })，不能漏掉metadata.，也不能写成contentType直接挂在根上 - mongofiles 命令行工具不支持按 metadata 查询，只能靠写脚本或用 mongosh
常见错误现象与排查顺序
查不到？别急着改代码，先按这个顺序检查：
- 用
mongosh连上去，执行db.fs.files.findOne()，确认返回文档里真有metadata.contentType字段 - 检查查询语句是否用了双引号包裹值（如
"image/jpeg"），单引号在某些 shell 环境下会被吃掉 - 确认大小写一致：HTTP 的
Content-Type是大小写不敏感的，但 MongoDB 查询是严格区分大小写的 - 如果用的是旧版驱动（
mongoclientv3.x 或更早），metadata可能被扁平化到顶层，此时得查{"contentType": "..."}—— 但这是反模式，应升级驱动并统一用嵌套写法
metadata、写得对不对，以及索引建没建对位置。这两个动作一旦漏掉或写错，后续所有查询都只是徒劳。 
