直接用multer-gridfs-storage可行但易出错：文件可能写入空集合、元数据丢失或下载报chunk size mismatch；常见查询不到文件是因bucketName不一致、未建filename索引、或files文档未及时写入。
直接用 multer-gridfs-storage 是可行的，但容易因配置错位导致文件写进空集合、元数据丢失或下载时 Corrupted download: chunk size mismatch。它适合快速接入表单上传，不适合需要细粒度控制 chunk、并发写入或跨 bucket 读写的场景。
为什么 upload 后 find 不到文件？
常见现象是调用 bucket.find({ filename: 'xxx' }) 返回空数组，但 mongofiles --db myapp list 能看到文件。
- 默认
bucketName是"fs"，但multer-gridfs-storage初始化时若传了bucketName: "uploads"，实际会写入uploads.files和uploads.chunks，而你查的是fs.files -
multer-gridfs-storage内部用的是GridFSBucket，但它把filename当作唯一键写入files.filename，而 MongoDB 的find不会自动加索引——必须手动在uploads.files上建{ filename: 1 }索引，否则查询极慢甚至超时 - 上传时若没等
uploadStream.on('finish')就去查，files文档可能还没写入（MongoDB 写入不是强实时）
multer-gridfs-storage 初始化的关键参数陷阱
这个包封装了底层逻辑，但几个选项稍不注意就会让文件“消失”在别的库或集合里：
用于自动切换项目中适合的node 版本
下载
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
-
url必须指向目标数据库，例如mongodb://localhost:27017/myapp；如果只写mongodb://localhost:27017，它会默认连到test库，文件就存进去了却找不到 -
bucketName默认是"fs"，但你设成"backups"后，所有操作（上传/查/删）都必须用同一个名字，否则读写分离 -
chunkSizeBytes必须显式指定且与读取端一致；默认是255 * 1024（255KB），若服务 A 用262144（256KB）上传，服务 B 用默认值下载，就会报chunk size mismatch -
file选项里的metadata是 BSON 对象，字段名不能叫_id或filename，否则被 GridFS 覆盖，白写
上传后怎么安全验证是否成功？
别依赖 Node.js 层的 on('finish') 就认为稳了——网络抖动、副本集同步延迟都可能导致 files 文档延迟写入或失败。
- 先用命令行确认：运行
mongofiles --db myapp list，应看到一条记录；再查mongofiles --db myapp search example.pdf，输出应含length和uploadDate - 检查
myapp.uploads.files集合是否存在文档：db.uploads.files.findOne({ filename: "example.pdf" })，注意集合名前缀要和bucketName一致 - 用
db.uploads.chunks.countDocuments({ files_id: ObjectId("xxx") })核对 chunk 数量是否匹配文件大小（比如 50MB 文件 / 255KB ≈ 200 个 chunk） - 如果用 Express + multer，确保
req.file对象里有id字段（ObjectId类型），这是后续下载的唯一可靠依据，别只信filename
最常被忽略的一点：GridFS 的 files 和 chunks 集合不在同一事务中，所以无法保证原子性。上传中途崩溃，可能留下孤立的 chunks 文档。生产环境必须配定期清理脚本，或用 bucket.delete() 配合 files_id 手动兜底。
