GridFS 文件总长度必须从 files 集合查询，不能依赖流对象的 length 属性；正确做法是通过 gridFSBucket.findOne({ _id: fileId }) 获取文件文档的 length 字段，再在 data 事件中累加 chunk.length 计算实时进度。
GridFS 文件流没有内置 length 属性，不能直接用 stream.length
GridFS 存储的文件被切分成多个 chunks，每个 chunk 默认 255KB，files 集合里存的 length 字段才是完整文件大小（单位字节），但这个值不会自动挂到 Node.js 的 ReadableStream 实例上。常见错误是试图读 stream.length 或 stream.headers['content-length'] —— 这些在 GridFS 流中都是 undefined。
正确做法是：先查 files 集合拿到目标文件的 length，再在流读取过程中累加已读字节数。
如何安全获取 GridFS 文件的总长度
必须通过 gridFSBucket.find() 或 gridFSBucket.openDownloadStream() 的 id 查 files 文档，不能依赖流对象本身。
- 使用
gridFSBucket.find({ _id: fileId }).toArray()，取返回数组首项的length字段 - 或更高效：用
gridFSBucket.findOne({ _id: fileId })（注意不是openDownloadStream的返回值） - 如果用的是
filename查询，需确保唯一性，否则可能匹配多个文件，length取值不可靠 - 注意：MongoDB 驱动 v4+ 中
findOne返回 Promise，需await；v3 则是回调风格
监听 data 事件累加已读字节数并计算进度
Node.js ReadableStream 的 data 事件每次触发时传入一个 Buffer，它的 .length 就是本次读取的字节数。把每次的字节数累加，除以总 length，就能得到实时进度（0–1）。
示例关键逻辑：
const totalLength = fileDoc.length; // 从 files 集合查出
let bytesRead = 0;
<p>stream.on('data', (chunk) => {
bytesRead += chunk.length;
const progress = bytesRead / totalLength; // 0.0 ~ 1.0
console.log(<code>Progress: ${(progress * 100).toFixed(1)}%</code>);
});</p><p>stream.on('end', () => {
console.log('Done. bytesRead === totalLength:', bytesRead === totalLength);
});</p>- 不要用
stream.readableLength—— 它只反映内部缓冲区剩余可读字节数，不是累计值 - 避免在
data回调里做重操作（如频繁 DOM 更新），可用requestIdleCallback或节流 - 如果文件极小（data，进度会直接跳到 100%
注意分块边界与流暂停行为对进度平滑性的影响
GridFS 流底层按 chunk 拉取，网络延迟或磁盘 IO 可能导致 data 事件间隔不均，造成进度条“卡顿”。这不是计算错误，而是真实读取节奏。
- 若需更平滑的 UI 进度，可在前端用插值（如 requestAnimationFrame + 上次进度 → 目标进度）过渡，而非完全依赖后端事件频率
- 调用
stream.pause()/resume()不影响bytesRead累加逻辑，但会中断事件流，暂停期间进度停滞 - 如果服务端启用了压缩（如 gzip），GridFS 不处理，所以
length和实际传输字节数不同 —— 但进度条应基于解压后的内容长度，即files.length，这是正确的
真正容易被忽略的是：很多项目直接拿 stream 当普通 HTTP 流处理，忘了 GridFS 的元数据必须单独查一次，而且这个查询和流打开是两个独立异步操作，没等 length 返回就开流，会导致初始进度 NaN。
