不能直接用fs.createwritestream，因gridfs非普通文件系统，需用openuploadstream确保元数据写入和分块逻辑正确；读取应使用opendownloadstream返回的readablestream直连sharp防oom。
GridFS 存储图片时为什么不能直接用 fs.createWriteStream？
因为 GridFS 是 MongoDB 的文件分块存储机制，不是普通文件系统。直接往 GridFS 写入流会丢失元数据（如 filename、contentType），且无法正确触发分块逻辑。必须用 gridFSBucket.openUploadStream。
- 错误做法：
fs.createWriteStream+pipe到 GridFS 的底层write方法 → 文件写入失败或读取时损坏 - 正确做法：用
gridFSBucket.openUploadStream创建上传流，再将原始 Buffer 或 ReadableStreampipe进去 - 务必设置
contentType（如"image/jpeg"），否则后续 Sharp 识别 MIME 类型可能出错
Sharp 裁剪缩略图前，如何从 GridFS 安全读取原始图片？
不能先 downloadToStream 再传给 Sharp —— 这会把整个文件加载进内存，大图（>10MB）极易 OOM。应使用 gridFSBucket.openDownloadStream 返回的 ReadableStream 直接对接 Sharp。
-
openDownloadStream返回的是 Node.js 原生Readable流，可直接pipe给sharp() - 务必在
openDownloadStream时传入_id或filename，避免查不到文件返回空流导致 Sharp 报Input buffer contains unsupported image format - 如果用
filename查询，注意 GridFS 默认不建索引，高并发场景下建议对files.filename手动加索引：db.fs.files.createIndex({ filename: 1 })
动态裁剪时 Sharp 的 resize 和 extract 怎么选？
取决于你是否需要保持宽高比。缩略图通常要等比压缩后居中裁切（cover 模式），而不是简单拉伸（contain 模式）。
- 用
resize(width, height, { fit: 'cover', position: 'center' })→ 等比缩放后裁掉溢出部分，适合头像、卡片图 - 用
extract({ left, top, width, height })→ 手动指定裁剪区域，适合固定坐标截图（如 UI 截图标注） - 别漏掉
jpeg({ quality: 80 })或png({ compressionLevel: 6 })，否则默认质量太高，体积翻倍 - 如果原始图是 PNG 但缩略图不需要透明通道，加
removeAlpha()可显著减小体积
缩略图生成后怎么存回 GridFS 并关联原图？
不要新建一个独立的 bucket，而是在同一 bucket 中用命名约定区分原图与缩略图，并通过 metadata 字段建立双向引用。
- 缩略图
filename推荐格式："${originalId}_thumb_200x200.jpg"，便于调试和清理 - 在
metadata中写入：{ originalId: ObjectId("..."), type: "thumbnail", width: 200, height: 200 } - 存完缩略图后，**不要**再去更新原图的
files文档 —— GridFS 的files集合是只读的，所有元数据应存在业务集合里（如images表） - 如果缩略图需权限控制，直接在业务层校验用户是否有权访问对应
originalId，而非依赖 GridFS 权限（GridFS 本身无权限模型）
error 事件并统一 reject Promise，否则请求会卡住直到超时。
