Blob API 是前端处理二进制数据的核心工具，其关键在于理解 Blob 的不可变性、slice 的字节级分段逻辑，以及结合流式读取或分块上传避免内存溢出；创建时需显式声明 MIME 类型，切片须按字节偏移计算防止越界，分块上传应控制并发并支持断点续传，流式处理虽省内存但依赖服务端协同。
Blob API 是前端处理二进制数据的核心工具，创建、切片与上传大数据块并不需要复杂框架，关键在于理解 Blob 的不可变性、slice 的分段逻辑，以及如何配合流式读取或分块请求避免内存溢出。
创建 Blob：支持多种数据源，类型必须显式声明
构造 Blob 时，第一个参数是数据数组（可混合 DOMString、Uint8Array、ArrayBuffer 或另一个 Blob），第二个参数是配置对象。MIME 类型 type 虽可省略，但强烈建议明确指定，否则下载时可能无法正确识别文件格式。
- 文本内容：用
new Blob(['内容'], { type: 'text/plain' }) - JSON 数据：先
JSON.stringify()再包裹，如new Blob([JSON.stringify(obj)], { type: 'application/json' }) - 二进制图像/音频：传入
Uint8Array或ArrayBuffer，并指定对应 MIME，例如'image/png'或'audio/wav' - 注意
endings参数仅影响字符串中的换行符处理，日常使用保持默认'transparent'即可
切片大文件：用 slice() 按字节边界分割，不是按“文件个数”
blob.slice(start, end, type) 返回新 Blob，原 Blob 不变。切片单位是字节，不是“第几块”，因此需循环计算偏移量。常见误区是直接用 Math.ceil(blob.size / chunkSize) 算总块数再硬拆——实际应以 start 和 end 为准，防止最后一块越界。
- 推荐 chunkSize 设为 1–5 MB（如
2 * 1024 * 1024），兼顾网络稳定性和浏览器内存压力 - 每次调用
blob.slice(i, Math.min(i + chunkSize, blob.size))，确保末尾不超限 - 切片后每个子 Blob 都拥有独立
size和type，可单独上传或校验
分块上传：结合 Promise 队列与进度反馈，避免并发失控
上传本身不依赖 Blob API，但切片后的每个 Blob 可作为 FormData 的值或直接作为 fetch body。重点在于控制并发、重试机制和中断恢复。
- 不要一次性发起全部请求，用串行或限制并发数（如最多 3 个同时上传）
- 每块上传时携带唯一标识（如
chunkIndex、totalChunks、fileId），便于服务端拼接 - 上传成功后记录已传索引，刷新页面也能续传（需前端保存状态到 localStorage 或 IndexedDB）
- 可监听
fetch的ReadableStream实现上传进度，但需服务端支持Content-Range头
补充：流式处理适合超大文件，但需服务端协同
对 GB 级文件，blob.stream() 提供 ReadableStream，能边读边传，显著降低内存占用。但该能力依赖服务端支持流式接收（如接收 multipart/mixed 或自定义二进制流协议）。
- 调用
blob.stream().getReader()获取 reader，用read()循环读取Uint8Array块 - 每次
read()返回{ done, value }，value是当前 chunk 的Uint8Array - 注意流只能读一次，且需手动
reader.releaseLock()释放资源 - 相比
slice，流式更省内存，但调试和错误定位更复杂，建议优先用分片方案
