缩略图与原图双向关联必须通过GridFS的metadata字段显式存储original_id（ObjectId类型），不可依赖文件名或时间戳；需建索引、手动级联删除，并确保查询时类型严格一致。
直接存缩略图本身不难，难的是让缩略图和原始文件能双向关联、可查可删。GridFS 本身不提供父子关系建模能力，必须靠 metadata 字段显式维护这种引用。
缩略图的 metadata 必须包含原始文件 _id
GridFS 的 files 集合支持任意键值对存入 metadata，这是唯一可靠的方式把缩略图和原图绑在一起。不要用文件名匹配、时间戳对齐或业务 ID 拼接——这些都不可靠。
-
metadata中至少要存一个字段，比如"original_id"，值为原始文件的ObjectId（不是字符串） - 如果原始文件是 PHP 存的，
$id是MongoId对象，直接传给storeBytes()的metadata即可；Java 中要用new ObjectId("...")构造后塞进BasicDBObject - 避免把
original_id存成字符串（如"5c0f7c374fc404123403d69e"），否则后续用{$expr: {$eq: ["$metadata.original_id", "$_id"]}}做聚合查询会失败
查询缩略图时别只查 filename，要用 metadata 精确匹配
缩略图通常命名为 xxx_thumb.jpg，但仅靠名字无法确认归属。真正安全的查法是基于 metadata.original_id 反查。
- PHP 示例：
$thumbs = $gridfs->find(['metadata.original_id' => new MongoId($originalId)]); - Java 示例：
BasicDBObject query = new BasicDBObject("metadata.original_id", new ObjectId(originalIdStr)); - 注意：MongoDB 4.2+ 支持在
files集合上对嵌套字段metadata.original_id建索引，务必加：db.fs.files.createIndex({"metadata.original_id": 1})
删除原始文件时，缩略图不会自动消失
GridFS 没有级联删除机制。删了原图，缩略图还在 fs.files 和 fs.chunks 里占空间，变成孤儿数据。
- 必须手动清理：先查出所有
metadata.original_id === 原图_id的缩略图_id，再逐个调用delete() - Java 中用
gridFS.delete(thumbObjectId)；PHP 中用$gridfs->remove(['_id' => $thumbId]) - 如果业务允许，也可把缩略图和原图存在不同 bucket（如
fs存原图，thumbs存缩略图），这样删除逻辑更隔离，但需额外管理多个 bucket 的连接和权限
最关键的细节是：原始文件 ID 在缩略图 metadata 中必须保持为原生 ObjectId 类型，且查询/删除时类型必须严格一致——差一个类型转换，就查不到、删不掉、也聚合不了。
