不能直接用fs.createReadStream管道到bucket.openUploadStream，因为后者返回的Writable流不支持pipe()自动错误传播和结束处理，网络中断时会静默失败；必须手动监听error、显式调用end()，或改用stream.pipeline()确保错误传递与流销毁。
GridFS上传大文件时，为什么不能直接用 fs.createReadStream 管道到 bucket.openUploadStream？
因为 openUploadStream 返回的是一个 Writable 流，但它不支持标准的 pipe() 自动错误传播和结束处理——一旦底层网络中断或 MongoDB 连接闪断，pipe() 会静默失败，文件写入一半就卡住，且不抛错。
实操建议：
- 必须手动监听
uploadStream.on('error', ...)，否则上传失败无感知 - 必须显式调用
uploadStream.end()，不能只靠pipe()自动触发（尤其在流提前结束时） - 推荐用
stream.pipeline()替代pipe()，它会在任一环节出错时自动销毁所有流并传递错误
const { pipeline } = require('stream');
pipeline(
fs.createReadStream(filePath),
bucket.openUploadStream(filename, { metadata: { type: 'video' } }),
(err) => {
if (err) console.error('Upload failed:', err.message);
else console.log('Upload complete');
}
);上传时如何设置文件名、contentType 和自定义元数据？
openUploadStream 的第二个参数是选项对象，不是 headers 或 formData——它直接映射到 GridFS 文件文档的 metadata 字段，contentType 需单独传，不是 metadata 里的键。
常见误区：把 contentType 写进 metadata，结果浏览器下载时无法识别类型。
正确写法：
-
filename是必需字段，决定 GridFSfiles集合中的filename值 -
contentType必须作为顶层选项传入，如{ contentType: 'application/pdf' } - 其他字段（如用户ID、上传时间）放进
metadata对象里，后续查库可直接用find({ 'metadata.userId': 'abc' })
bucket.openUploadStream('report.pdf', {
contentType: 'application/pdf',
metadata: {
userId: 'u123',
uploadedAt: new Date(),
version: 2
}
});上传后怎么获取文件 ID 并用于后续下载或删除？
openUploadStream 返回的流本身没有 _id，ID 是在写入完成、服务端确认后才生成的——所以必须监听 'finish' 事件，此时流已关闭，uploadStream.id 才可用。
容易踩的坑：
- 在
uploadStream.on('close', ...)里取id，但close可能早于实际写入完成，id为undefined - 误以为
uploadStream是 Promise，试图await uploadStream，但它根本不是 Promise - 没保存
uploadStream.id，导致后续无法用bucket.find({ _id: fileId })查文件
安全做法：
const uploadStream = bucket.openUploadStream(filename);
uploadStream.on('finish', () => {
console.log('File stored with ID:', uploadStream.id.toString());
// 这里存 ID 到业务数据库或返回给前端
});
fs.createReadStream(filePath).pipe(uploadStream);Node.js 服务重启或上传中途崩溃，怎么避免文件残留？
GridFS 不会自动清理未完成上传的 chunks。如果流中断（如进程 kill、OOM、网络断开），对应 chunks 集合里会留下碎片，files 集合也可能多出一条 length: 0 的脏记录。
解决思路分两层：
- 上传前：用
bucket.find({ filename, uploadDate: { $gt: Date.now() - 5 * 60 * 1000 } })检查是否已有同名未完成上传，有则先delete掉 - 上传后：定期运行
bucket.drop()清理整个 bucket（慎用），或更稳妥地用bucket.delete(fileId)配合业务逻辑清理异常项 - 生产环境建议加个定时任务，每天扫描
files集合中length: 0或uploadDate超过 1 小时的文档并删除
真正麻烦的是 chunks 僵尸块——它们没有索引关联，只能靠 files._id 与 chunks.files_id 匹配清理，别漏掉这步。
