gridfs chunksizebytes 必须与前端分片大小对齐，如前端请求1mb range则后端chunksize应设为256kb以实现4块精准匹配；node.js需手动解析range、按序读取并裁剪chunks；前端须用readablestream分块消费而非blob()。
GridFS chunkSizeBytes 必须对齐前端分片大小
前端发 Range: bytes=0-1048575（即 1MB），后端却用默认 255KB chunk，MongoDB 驱动就得读 5 个 fs.chunks 文档、拼接、再裁剪——I/O 和内存白耗。这不是性能问题，是设计错位。
- 显式创建 bucket 时设
chunkSizeBytes: 262144（256KB），刚好 4 个 chunk 组成 1MB，完全对齐 - 用
db.fs.chunks.find({ files_id: ObjectId("...") }).sort({ n: 1 }).limit(5)检查实际n是否连续、data字段长度是否接近 262144 - 别设 4MB chunk：小文件仍占一整块，空间浪费翻倍；单次读延迟上升，流式响应卡顿更明显
Node.js 后端必须手动解析 Range 并构造精准流
GridFS 本身不识别 HTTP Range 头，bucket.openDownloadStream() 返回的是完整文件流，直接 pipe 就等于全量传输——和“按需”背道而驰。
- 先查
fs.files获取文件总长：const fileDoc = await bucket.findOne({ filename: "video.mp4" }) - 根据
req.headers.range解析起始偏移和结束位置，注意处理bytes=500000-这类末尾未指定的情况，要用fileDoc.length补全 - 计算覆盖该 range 的所有
chunk序号（n），按序查fs.chunks，逐个读data字段并截取有效字节段 - 用
stream.Readable手动 push 数据块，而不是 accumulate buffer 再 write——避免内存堆积
前端 fetch + Blob 不等于按需加载
即使后端返回了正确的 206 Partial Content 和精确字节段，response.blob() 仍会阻塞等待整个流结束，对百 MB 视频或 GB 级模型文件毫无意义。
- 改用
response.body.getReader()+read()分块消费，配合Uint8Array直接喂给MediaSource或 WASM 模块 - 不要调
response.arrayBuffer()或response.text()，它们隐式等待流关闭 - 若必须生成 URL，用
new Blob([chunk], { type: "video/mp4" })单块构造，再URL.createObjectURL()，而非等全部数据到位
openDownloadStream() 传参错误导致空流是高频陷阱
bucket.openDownloadStream("report.pdf") 看起来直觉，但只会返回空流或抛 TypeError: Cannot read property '_id' of null ——它不接受字符串，只认 ObjectId 或已查出的文档。
- 必须两步走：
const doc = await bucket.findOne({ filename: "report.pdf" })，再bucket.openDownloadStream(doc._id) - 文件名含中文或空格时，确保查询字段与存储时完全一致（MongoDB 区分大小写、不自动 trim）
-
contentType和Content-Disposition都得手动设：res.setHeader("Content-Type", doc.contentType || "application/octet-stream")，中文名记得encodeURIComponent(doc.filename)
真正难的不是写几行流代码，而是把 chunk 边界、HTTP range 解析、前端消费链路三者严丝合缝地对齐——少一个环节，“按需”就退化成“假装按需”。
