GridFS分类能力取决于metadata字段结构化程度及fs.files上的复合索引。需用扁平、类型明确的metadata（如metadata.type="pdf"、metadata.year=2024），避免嵌套或字符串拼接；必须在fs.files建复合索引（如{"metadata.dept":1,"metadata.year":-1,"metadata.type":1}），查询时路径与类型须严格匹配。
GridFS 本身不分类，分类能力完全取决于你写入时填的 metadata 字段是否结构化、可索引，以及后续是否在 fs.files 上建对了复合索引。
写入 PDF 时 metadata 必须是扁平对象，不能是字符串或嵌套结构
常见错误是把类型信息塞进字符串字段，比如 {"tags": "pdf,2024,finance"}——这会让按年份或部门查变成正则扫描，毫无性能可言。正确做法是用明确键名+合适类型：
-
metadata.type固定为"pdf"（小写，统一） -
metadata.year用整数，如2024，不是"2024" -
metadata.dept用规范缩写，如"fin"或"hr"，避免空格和大小写混用 - 别用
metadata.classification = { level: "confidential", scope: "internal" }这种嵌套——索引效率低，查询语法也复杂 - Go Driver 中传
map[string]interface{}，不是 struct；Python PyMongo 中直接传 dict，字段名必须和索引路径一致
必须在 fs.files 上建复合索引，chunks 集合建索引没意义
fs.chunks 只存二进制分块，不含业务元数据，所有检索逻辑都落在 fs.files。不建索引的 metadata 字段等于不存在。
- 高频查询组合是部门 + 年份 + 类型，建索引命令：
db.fs.files.createIndex({"metadata.dept": 1, "metadata.year": -1, "metadata.type": 1}) - 字段路径必须带
metadata.前缀，且大小写完全匹配——Metadata.Type和metadata.type是两个字段 - 如果还常按上传时间排序，把
uploadDate加进复合索引末尾，但别放前面（基数太低） - 确认生效：运行
db.fs.files.getIndexes()，看输出里有没有你刚建的那条
用 find() 检索时，查询条件必须匹配 metadata 路径和值类型
即使 metadata 写对了、索引也建了，查询语句错一个点就全盘失效。
- Node.js 驱动：用
bucket.find({ "metadata.dept": "fin", "metadata.year": 2024, "metadata.type": "pdf" })，不能漏metadata. - PyMongo GridFSBucket：同理，
bucket.find({"metadata.dept": "fin"})，别用旧版GridFS类的find_one({"filename": ...})，它不支持 metadata 查询 - Spring Data MongoDB：用
Query.query(Criteria.where("metadata.dept").is("fin"))，注意引号和点号 - 值类型必须一致：查
"metadata.year": 2024时，传字符串"2024"就匹配不上 - mongofiles 命令行工具完全不支持 metadata 查询，调试时务必用
mongosh直连验证
最易被忽略的一点：GridFS 不校验 metadata 结构，写错字段名、类型或路径，不会报错，只会让后续所有查询静默失败。上线前务必用 db.fs.files.findOne() 抽样检查真实文档结构，再比对索引字段和查询语句——三者必须严丝合缝。
