GridFS不支持Range请求，需手动解析Range头、计算chunk索引、精确截取BinData并返回206响应；关键点包括校验字节范围、按chunkSize对齐、设置正确响应头及索引优化。
GridFS 本身不支持 Range 请求，必须自己实现分片映射
GridFS 只是把大文件切块存成 chunks 和 files 两个集合，并不提供 HTTP 范围读取能力。浏览器快进依赖服务端响应 206 Partial Content 和正确的 Content-Range 头，这需要你手动解析请求里的 Range 头，算出对应 chunk 编号、偏移和长度，再拼接返回。
关键点在于：GridFS 的 chunk 默认大小是 255KB（261120 字节），但实际存储时最后一个 chunk 可能更小；且每个 chunk 的 data 字段是 BinData，不能直接拼接成流——必须按字节边界精确截取。
- 用
req.headers.range解析出起始字节（如bytes=1024000-或bytes=1024000-2047999） - 根据
chunkSize（从files文档中读取，非固定值）计算目标 chunk 索引：Math.floor(start / chunkSize) - 注意：首个 chunk 偏移是
start % chunkSize，后续 chunk 全部读满，末 chunk 截到end % chunkSize + 1 - 务必校验
start是否超出文件总大小（files.length），否则返回416 Range Not Satisfiable
Node.js + MongoDB Driver 实现 Range 响应的最小可行逻辑
不要依赖任何 GridFS 封装库的“流式读取”方法（如 openDownloadStream），它们默认不识别 Range，会全量加载。必须手写基于 find 查询特定 chunk 的逻辑。
示例核心片段（Express 中间件）：
bytes */${total}
Chrome/Safari 快进失败的三个典型原因
即使后端返回了 206，前端仍可能卡在 loading 状态或跳转失败，常见于以下情况：
-
Content-Range格式错误：必须严格为bytes 1024000-2047999/5242880，少空格、多斜杠、数字错位都会导致浏览器放弃 Range 请求 - 未设置
Accept-Ranges: bytes响应头，浏览器将忽略所有Range请求，强制走完整下载 - 音频文件未内嵌
duration或moovbox 在前（MP4 尤其明显）：浏览器无法预估总时长，拖动条不可交互；需用ffmpeg -i in.mp4 -c copy -movflags +faststart out.mp4重写
性能与并发要注意的实际限制
每次快进都触发多次 chunk 查询（最多几十次），在高并发下容易成为瓶颈。MongoDB 单次 find 查询多个 n 值效率尚可，但 chunk 数量过大（>100）时延迟上升明显。
- 避免在循环里逐个
findOne，必须用$in: [n1,n2,...]一次查完 - 给
fs.chunks集合确保有复合索引：{ files_id: 1, n: 1 }，否则排序和范围查询极慢 - 如果文件普遍 >50MB，考虑改用对象存储（如 S3）+ CDN，GridFS 并非为高频随机读优化
- 移动端弱网下，浏览器可能发送多个重叠 Range 请求，服务端需容忍重复或小范围请求，不必强校验顺序
真正麻烦的是 chunk 边界对齐——哪怕一个字节偏差，音频解码器就会爆破音或静音。别信“差不多”，每个 slice 起止必须严格按原始文件字节位置算。
