不建议用 GridFS 存头像，因默认 chunkSize 255 KiB 远超头像体积，导致 fs.chunks 膨胀、索引变大、查询变慢。
直接存用户头像到 MongoDB 的 fs.files 和 fs.chunks 是可行的，但默认配置下容易踩内存暴涨、查询慢、HTTP 服务难对接三个坑。不建议用 GridFS 存大量小图（比如头像），除非你明确需要跨分片一致性或统一备份策略。
GridFS 存头像时 chunkSize 设置不当会拖慢读取
默认 chunkSize 是 255 KiB，对几 KB 的头像来说严重浪费：每个头像都会占满一个 chunk 文档，导致 fs.chunks 膨胀数倍，索引变大，findOne() 查单个头像也要扫更多 chunk 文档。
- 头像类小文件（chunkSize: 4096（4 KB），平衡文档数量与 I/O 次数
- Node.js 驱动中创建 GridFS bucket 时传入：
new GridFSBucket(db, { bucketName: 'avatars', chunkSizeBytes: 4096 }) - 已存数据无法改 chunkSize，必须重写；
mongofiles命令不支持指定 chunk 大小，只能用驱动 API
Node.js 中用 GridFSBucket 写入头像的典型流程
别用过时的 GridStore（已废弃），也别把 Base64 字符串整个塞进 BSON —— 它会触发额外编码开销且不支持流式上传。
- 接收上传时用
multer或busboy解析multipart/form-data，拿到file.buffer或可读流 - 用
bucket.openUploadStream()创建上传流，把 buffer 或流 pipe 进去：uploadStream.end(file.buffer) - 务必在
uploadStream.on('finish', ...)回调里返回_id，别依赖uploadStream.id同步取值（它可能还没赋值） - 元数据如
userId、avatarType写进metadata对象，不是靠文件名解析
从 GridFS 读头像并返回 HTTP 响应的常见错误
直接 bucket.find({ filename: 'xxx' }).toArray() 再 streamToBuffer() 是最慢写法，内存占用高，还容易超时。
- 优先用
bucket.openDownloadStream(id)，配合 Express 的res流式转发：downloadStream.pipe(res) - 必须手动设置
Content-Type（如image/jpeg），GridFS 不自动推断；从files文档里读contentType字段 - 别用
findOne()加getBytes()—— 它会把整个头像加载进内存，1000 并发就可能 OOM - 如果要用 Nginx 直接代理 GridFS（如 nginx-gridfs 模块），注意它只认默认
fsbucket，自定义 bucket 名需额外配置
真正麻烦的不是写入或读取，而是当头像要频繁更新时：GridFS 没有原子替换，delete + put 之间存在窗口期，旧头像可能被缓存或已失效。生产环境更稳妥的做法是每次上传生成新 _id，在用户文档里只存最新 _id 引用，并加 TTL 索引自动清理历史版本。
