必须用GridFSBucket.openDownloadStream()获取流式二进制，不可直接查fs.files文档或拼接chunks；驱动已封装还原逻辑，手动操作易出错。
GridFS 存储的图片怎么提取原始二进制？
GridFS 本身不提供图像处理能力，必须先从 fs.files 和 fs.chunks 中还原完整文件。直接用 GridFSBucket.openDownloadStream() 获取流是最稳妥方式，避免手动拼接 chunk——MongoDB 驱动已封装好逻辑，手动拼容易漏 chunk 或顺序错。
常见错误是试图用 findOne() 查 fs.files 后直接读 data 字段：该字段不存在，GridFS 把文件切片存在 fs.chunks，fs.files 只存元信息。
- 用
bucket.find({ filename: "xxx.jpg" })定位文件，再传_id给openDownloadStream() - 不要依赖
metadata里的自定义字段做缩略图判断，优先用filename或_id精确匹配 - 流式读取时注意超时设置，大文件可能卡在
readable状态，建议加timeout选项
用 sharp 处理 GridFS 流生成缩略图靠谱吗？
靠谱，但必须确保流能被 sharp() 正确识别格式。GridFS 流默认无 Content-Type，sharp 依赖文件头（magic bytes）推断格式，所以不能跳过前几百字节——常见坑是提前 pipe 或 on('data') 消费了开头。
正确做法是把下载流直接传给 sharp()，它内部会 buffer 前 12KB 自动检测格式：
const stream = bucket.openDownloadStream(fileId);
const thumbnail = sharp(stream).resize(200, 200, { fit: 'inside' }).jpeg({ quality: 80 });
- 别用
stream.pipe(sharp().resize(...))，sharp的构造函数接受 ReadableStream，更稳定 - 如果原图是 WebP 或 AVIF，
sharp默认支持；但旧版 Node 可能缺 libvips 编译支持，运行sharp -V确认版本 ≥ 0.32.0 - 缩略图尺寸用
{ fit: 'inside' }保持比例，避免变形；若需裁剪用'cover'
缩略图存回 GridFS 还是另起集合？
存回同一个 GridFS bucket 最省事，但得避免命名冲突和清理麻烦。推荐用统一前缀区分，比如原文件 photo.jpg → 缩略图存为 thumb_photo.jpg，而不是塞进 metadata 当子文档——GridFS 不支持嵌套文件。
- 写入时用
bucket.openUploadStream("thumb_" + originalName, { metadata: { originalId: fileId } })，方便反查 - 别把缩略图和原图共用
_id，否则删除原图时缩略图也被删（除非你手动维护引用） - 如果缩略图访问极频繁，考虑导出到本地文件系统或 CDN，GridFS 读小文件性能不如直接文件服务
并发生成缩略图时怎么防重复？
多个请求同时发现某文件没缩略图，就会并发生成并写入，造成浪费。最轻量的解法是在写入前用 bucket.find({ filename: "thumb_xxx.jpg" }).toArray() 查重，但要注意竞态窗口。
真正可靠的方案是用 MongoDB 的 findAndModify 类操作——虽然 GridFS 没原生支持，但可以先在普通集合里建一个 thumbnails 表，用 upsert 记录状态：
db.thumbnails.findOneAndUpdate(
{ originalId: fileId },
{ $setOnInsert: { status: 'pending', createdAt: new Date() } },
{ upsert: true, returnDocument: 'after' }
)
- 返回
status === 'pending'就去生成；返回已有记录且status === 'done'就直接读缩略图 - 生成成功后更新
status并写入thumbnailId字段，失败则设为'failed'避免重试风暴 - 这个表必须建唯一索引：
{ originalId: 1 }，否则 upsert 失效
缩略图逻辑里最容易被忽略的是格式探测失败和并发写冲突，这两点不处理，上线后要么返回空白图，要么同一张图生成十几次。
