Blob本身不提升性能，但能绕过传统文件处理瓶颈：避免全量加载内存、跳过服务器中转、支持流式操作；应分块读取、及时释放引用、优先用URL.createObjectURL预览，构造File需继承Blob，fetch后用blob.stream()实现无压力解析。
Blob 本身不提升性能，但能帮你绕过传统文件处理的瓶颈——比如避免把大文件全读进内存、跳过服务器中转、实现流式操作。
为什么 FileReader.readAsArrayBuffer 会卡住页面
直接用 FileReader 读取几百 MB 的文件时，浏览器要把整个文件加载成 ArrayBuffer 放进 JS 堆内存，容易触发 GC 暂停甚至 OOM。这不是 Blob 的问题，而是“全量加载”模式的硬伤。
- 真正该做的是：用
Blob.slice()分块读，每次只处理几 MB - 配合
FileReader.readAsArrayBuffer()处理每一块，读完立刻释放引用 - 不要把所有分块 ArrayBuffer 拼成一个大数组——这又回到内存陷阱里
- 如果只是校验或预览，优先用
URL.createObjectURL(blob)直接交给<img>或<video>，浏览器内部用流式解码
用 Blob 构造“虚拟文件”绕过 input[type=file]
有些场景需要模拟用户选中文件（比如从 IndexedDB 恢复上次上传的文件），但 <input type="file"> 的 files 属性是只读的，无法赋值。这时 Blob 就是唯一合法出口。
- 从缓存读出二进制数据后，用
new Blob([uint8Array], {type: 'image/png'})构造新 Blob - 再用
new File([blob], 'recovered.png', {type: 'image/png'})包一层，获得带 name 和 lastModified 的类 File 对象 - 注意：
File必须继承自Blob，不能只传 raw bytes；否则某些上传库（如 axios）会拒绝处理 - 构造出的
File可直接用于FormData.append('file', file)，和真实选择无异
fetch + Blob 实现无内存压力的下载与解析
传统 fetch(url).then(r => r.json()) 会把整个响应体转成字符串再 parse，对大 JSON 或 CSV 文件极不友好。用 response.blob() 能保持二进制流形态，交由 Web Worker 或流式解析器处理。
立即学习“前端免费学习笔记（深入）”；
- 先调
fetch(url).then(r => r.blob())，得到Blob，不触碰内容 - 用
blob.stream().getReader()获取可中断的流读取器，逐 chunk 解析（适合 CSV / 日志等行协议） - 若需转文本，用
new TextDecoder().decode(chunk)，别用blob.text()——后者仍会把全部内容加载进内存 - 导出文件时，
URL.createObjectURL(blob)比URL.createObjectURL(new Blob([data]))更高效，因为前者复用原始 Blob 引用，后者多一次拷贝
真正难的不是怎么用 Blob，而是判断什么时候不该用它——比如小文件（FileReader.readAsText() 更简单；又比如需要服务端校验的场景，前端构造的 Blob 无法替代真实 input 的安全上下文。这些边界条件，文档里通常不写，但线上报错时第一个撞上。
