HTML Blob能否提升文件处理效果？

先说结论：Blob本身确实不提升性能，但它能帮你绕开传统文件处理中的那些“硬瓶颈”——比如大文件全量读进内存、数据非得经过服务器中转、或者没法做流式操作。说白了，Blob给前端提供了一条更轻巧的路径，而你真正要学的，是怎么用好这条路径。

为什么 FileReader.readAsArrayBuffer 会卡住页面

直接用FileReader去读几百MB的文件时，浏览器得把整个文件吞成ArrayBuffer，然后塞进JS堆内存。后果是什么？GC暂停、页面卡顿，严重了直接OOM（内存溢出）。这个问题根子在“全量加载”模式，不能怪Blob。你要做的就是换一套打法。

• 用Blob.slice()分块读取，每次只啃几MB
• 配合FileReader.readAsArrayBuffer()处理每一块，处理完立刻释放引用，别让数据堆积
• 千万别把所有分块的ArrayBuffer合并成一个巨大数组——那样又会掉回内存陷阱里
• 如果只是预览或做校检，优先用URL.createObjectURL(blob)，直接扔给或。浏览器内部会用流式解码，压力小得多

用 Blob 构造“虚拟文件”绕过 input[type=file]

有些时候，你想模拟用户选中一个文件——比如从IndexedDB恢复上次上传的文件。但的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对象
• 构造出的File可以直接用在FormData.append('file', file)里，和用户真实选择的文件效果一模一样

fetch + Blob 实现无内存压力的下载与解析

传统写法fetch(url).then(r => r.json())会把整个响应体转成字符串再解析。对大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的安全上下文。这些边界条件，文档里通常不提，但线上出bug时，第一个撞上的就是你。