GridFS本身不支持图片裁剪，需先用sharp等库在应用层处理裁剪，再将结果字节流存入GridFS；其仅负责将大文件分块存储至fs.files和fs.chunks集合，不解析或修改文件内容。
GridFS 本身不支持图片裁剪，必须先用其他库处理
GridFS 只是把大文件分块存进 fs.files 和 fs.chunks 集合，它不解析文件内容，更不会执行裁剪逻辑。你要裁剪图片，得先在应用层完成——比如用 sharp（Node.js）、Pillow（Python）或 ImageMagick 命令行工具。裁剪完再把结果字节流交给 GridFS 存储。
常见错误是试图让 GridFS “自动裁剪”，结果发现上传的还是原图，或者服务直接报错 TypeError: Cannot read property 'buffer' of undefined——那通常是因为你传了未处理的原始 Buffer 或空流。
- 裁剪必须在写入 GridFS 之前完成，且输出格式明确（如
jpeg、png） - 注意裁剪后图像的
Content-Type要同步更新，否则前端可能无法正确渲染 - 如果用
sharp，记得调用.toBuffer()获取最终 Buffer，不能直接传sharp(...).jpeg()这样的流对象给 GridFS
使用 mongod 客户端驱动的 GridFSBucket 写入裁剪后图片
Node.js 环境下推荐用官方驱动的 GridFSBucket，而不是旧版 GridStore（已弃用）。它支持流式写入，适合处理裁剪后的 Buffer 或 ReadableStream。
关键点：必须显式指定 contentType 和可选的 metadata，否则后续按 MIME 类型查图会失败。比如裁剪为 JPEG 后，contentType 必须设为 "image/jpeg"，不能留空或写成 "image/jpg"（后者不是标准值）。
const { GridFSBucket } = require('mongodb');
const bucket = new GridFSBucket(db);
const uploadStream = bucket.openUploadStream('avatar_200x200.jpg', {
contentType: 'image/jpeg',
metadata: { width: 200, height: 200, originalId: 'abc123' }
});
writeStream.pipe(uploadStream); // writeStream 来自 sharp 输出
-
filename建议带扩展名，否则 GridFS 不会自动推断contentType - 避免在
metadata中存二进制数据（如 base64），只放结构化字段，否则影响查询性能 - 如果并发上传同名文件，GridFS 默认覆盖——需要去重时，应先用
bucket.find({ filename: '...' })检查是否存在
按尺寸/类型查裁剪图时，别只依赖 filename
靠 filename 字段查图看似简单，但实际容易出问题：重命名、大小写、URL 编码差异都会导致查不到。更可靠的方式是用 metadata 建索引并查询。
例如，为快速查找所有 300×300 的头像图，先建索引：db.fs.files.createIndex({ "metadata.width": 1, "metadata.height": 1, "metadata.type": 1 })，再用：
bucket.find({
"metadata.width": 300,
"metadata.height": 300,
"metadata.type": "avatar"
})
-
filename在 GridFS 中不是唯一键，files._id才是主键；多个同名文件可共存 - 查询时若没加
contentType条件，可能捞到 PDF 或 SVG（它们也可能被误存为同名） - 用
bucket.find().toArray()拿结果前，确认游标没被提前消耗（比如 forEach 后再 toArray 会返回空数组）
裁剪参数变更后，旧图不会自动更新
这是最容易被忽略的运维陷阱：你改了裁剪逻辑（比如从等比缩放改成居中裁切），但 GridFS 里仍存着旧图，新请求却可能读到缓存里的老文件，用户看到的还是变形图。
- 上线新裁剪规则前，必须决定是否批量清理旧图——可通过
metadata.version字段标记，并在查询时加条件过滤 - 不要依赖“覆盖同名文件”来更新，因为
openUploadStream默认不删旧文件，只是新增一个版本 - 如果业务要求强一致性，建议在写入新图后，用
bucket.delete(id)主动删掉对应旧_id，而不是靠 filename 匹配（可能匹配到多个）
真正麻烦的不是怎么存，而是怎么管住那些静默躺在 fs.chunks 里、没人认领的废弃块——它们不会随文件删除自动回收，得靠 db.fs.chunks.validate() 或定期 db.runCommand({ repairDatabase: 1 }) 清理。
