GridFSDownloadStream 读大视频易OOM，因其默认不控流；须设 readableHighWaterMark（如2MB）并用 pipe() 配合背压处理，或手动查chunks实现Range请求；推荐改用S3+元数据或文件系统托管视频。
GridFSDownloadStream 读取大视频文件时卡住或内存暴涨？
直接用 GridFSDownloadStream.read() 一次性读完整个视频流，几乎必然导致 OOM 或超时。MongoDB 的 GridFS 本身不提供“流式播放”语义，GridFSDownloadStream 是可读流（Readable Stream），但默认行为取决于你如何消费它——不控制 chunk 大小、不及时暂停、不处理背压，Node.js 就会把整个文件缓存在内存里。
关键不是“能不能读”，而是“怎么让下游消费速度跟上上游吐出速度”。常见错误包括：
- 用
stream.on('data', callback)但没在 callback 内部调用stream.pause()+ 异步处理后stream.resume() - 用
pipeline()但目标写入目标（比如fs.createWriteStream）阻塞了，而源流没做限速 - 误以为
GridFSDownloadStream自带分片逻辑，其实它只是按内部chunkSizeBytes（默认 255KB）从数据库拉数据，但你不主动控制读节奏，驱动层仍可能预加载多 chunk
用 pipe() + highWaterMark 控制每批读取量
最简稳方案是走 Node.js 原生流管道，但必须显式设 highWaterMark，否则默认 16KB 对视频流太小，频繁触发 read()；太大又失去流控意义。建议设为 1–2MB，匹配典型视频 GOP 大小。
示例（Express 中响应视频流）：
const stream = bucket.openDownloadStream(fileId);
// 关键：限制内部缓冲区，避免内存堆积
stream.setEncoding('binary');
stream.readableHighWaterMark = 1024 * 1024 * 2; // 2MB
<p>res.writeHead(200, {
'Content-Type': 'video/mp4',
'Accept-Ranges': 'bytes',
'Content-Length': file.length // 注意：file.length 是总大小，非实时
});</p><p>stream.pipe(res);</p>
注意：stream.pipe(res) 本身会自动处理背压，但前提是 res 不被意外中断（如客户端断连）。生产中务必监听 stream.on('error') 和 res.on('close') 做清理。
需要精确控制分段（如支持 HTTP Range 请求）？别依赖 GridFSDownloadStream 自身
GridFSDownloadStream 不支持随机 seek 或按 byte range 初始化。想实现视频拖拽（HTTP 206 Partial Content），你必须自己计算 chunk 范围，再用 bucket.find() 手动查对应 chunks 文档，拼接返回。
步骤如下：
- 解析请求头
Range: bytes=1000000-1999999 - 根据
file.chunkSizeBytes（如 255KB）算出起始 chunk index 和偏移：startChunk = Math.floor(start / chunkSize)，startInChunk = start % chunkSize - 用
bucket.find({ files_id: fileId, n: { $gte: startChunk, $lte: endChunk } })查 chunks，按n排序 - 对首尾 chunk 截取有效字节，中间 chunk 全取
data字段（Binary）
这比直接用 openDownloadStream 复杂得多，但只有这条路能真正支持秒开、拖拽、CDN 缓存。别试图给 GridFSDownloadStream 加 offset 参数——它没有。
为什么不用 GridFS？考虑替代方案
GridFS 是为“大但不常变”的文件设计的（如用户头像、PDF 报告），不是为高频、低延迟、随机访问的视频流优化的。实际项目中，更常见的做法是：
- 只用 MongoDB 存元数据（
filename,duration,s3_key），视频本体扔到 S3 / MinIO / CDN，用 presigned URL 直播 - 若必须本地存储，改用普通文件系统 + Nginx 的
sendfile或slice模块，性能高一个数量级 - 真要 MongoDB 托管流，评估 MongoDB 7.0+ 新增的
$binary字段 + 聚合管道流式输出能力，但目前仍不成熟
GridFSDownloadStream 的“流式”是假流式——底层仍是同步拉 chunk 文档。真正瓶颈不在 JS 层，而在 MongoDB 单次查询返回 chunk 的网络往返和 BSON 解析开销。这点容易被忽略。
