GridFS视频拖动卡顿主因是chunkSize与前端分片不匹配、两次查询、未解析Range及前端blob等待整流；需设chunkSize为分片整数倍、用openDownloadStreamByName、手动解析Range并流式响应、前端用getReader()分段处理。
GridFS chunkSize 与前端分片不匹配导致跨 chunk 读取
拖动播放卡顿，90% 是因为后端 chunk 边界和前端 Range 请求没对齐。比如前端按 1MB 分片（bytes=1048576-2097151），但 GridFS 默认用 255KB（261120 字节）分块，一个 1MB 区间大概率横跨 4–5 个 chunk，驱动就得读、拼、裁，白白多出 3–4 次磁盘 I/O 和内存拷贝。
- 检查当前 chunk 大小：
db.fs.files.findOne({ filename: "xxx.mp4" })看chunkSize字段值 - 创建 bucket 时显式设为分片粒度的整数倍：前端用 1MB 分片 → 设
chunkSizeBytes: 262144（即 256KB），4 个 chunk 刚好 1MB - 避免设成 4MB 或更大：单次读延迟上升，且小文件（如封面图）仍占一整个大 chunk，浪费空间又拖慢索引扫描
openDownloadStreamByName 没用，导致两次独立查询
很多代码先查 files 集合拿到 _id，再调 openDownloadStream(file._id) —— 这是两次独立查询，中间还夹着一次 BSON 解析和网络往返。机械硬盘上，这等于多等一次寻道时间，拖动时感知明显。
- 必须用
bucket.openDownloadStreamByName("xxx.mp4")（MongoDB 4.4+），它把元数据查 + 流初始化合并为一次请求 - 确认驱动版本：Node.js driver ≥ 4.0，Go driver ≥ 1.10，旧版不支持该方法
- 别在
openDownloadStreamByName后再手动 pipe 到 response；应直接接response.write()或fs.createWriteStream()，跳过中间 Buffer 缓存
后端没做 Range 解析，全量流式吐出
GridFS 本身不识别 HTTP Range 头。如果后端收到 Range: bytes=500000- 却直接调 openDownloadStreamByName 并整文件流式返回，浏览器就得丢弃前 500KB，白跑一趟。
- 必须手动解析
req.headers.range，算出起始偏移start和长度end - 用
bucket.find({ filename: "xxx.mp4" })查出length和_id，再根据start / chunkSizeBytes算出要读的 chunk 起始序号n - 逐个读
fs.chunks文档，对每个data字段截取有效字节段（注意首尾 chunk 的偏移裁剪），再 push 到自定义Readable流 - 响应头务必设
Content-Range和Content-Length，否则浏览器无法正确续播
前端用 blob() 等待整流结束
即使后端精确返回了 206 Partial Content，如果前端写 response.blob().then(...)，浏览器会等整个流关闭才生成 Blob —— 拖动时用户其实在等“下一个关键帧”，结果卡住不动。
- 改用
response.body.getReader()，循环调read()拿Uint8Array片段 - 片段拿到后，直接送入
MediaSource.appendBuffer()（视频）或WebAssembly.Memory（模型文件） - 避免在内存里拼大 Buffer：超过几 MB 就可能触发 V8 GC，造成 JS 线程卡顿
