blob怎么用：实测上手记录
blob怎么用，关键不在记概念，而在理解它适合处理哪类数据。我实测下来，Blob更像浏览器里的“临时文件容器”，适合下载、预览、分片上传和前端生成文件；但如果把它当普通字符串用，性能和兼容性都会出问题。
总述：Blob适合解决什么问题
从实际使用看，Blob最稳定的价值是承接二进制或类文件数据。比如把后端返回的PDF流保存为文件、把Canvas生成的图片导出、把文本内容临时生成CSV下载，这些场景用Blob都比较顺手。正面看，它不依赖服务器落盘，前端即可完成文件构造；反面看，它不是万能存储，也不适合长期保存大量数据。
我第一次用Blob，是给后台系统做“导出报表”按钮。后端返回的是ArrayBuffer，前端用new Blob包装后，再通过URL.createObjectURL生成临时地址。整个流程比拼接data URL更稳，尤其文件超过几MB后，差距很明显。
用法一：生成文本文件下载
最容易上手的blob怎么用场景，是前端生成txt或csv。核心代码通常是：const blob = new Blob([content], { type: 'text/csv;charset=utf-8' }); 然后创建a标签触发下载。这里的content可以是字符串，也可以是数组片段。
实测中，CSV文件要特别注意BOM。Excel在部分中文环境下打开UTF-8 CSV可能乱码，解决方式是在内容前加'\ufeff'。这个细节不是Blob本身的问题，而是应用软件识别编码的差异。正面方案是兼容办公软件，反面代价是文件开头多了BOM标记。
用法二：预览图片和PDF
Blob还常用于预览。用户选择本地图片后，File对象本身就是Blob的子类，可以直接用URL.createObjectURL(file)生成预览地址。相比FileReader转base64，这种方式内存占用通常更可控，代码也更短。
但这里有一个实测必须强调的点：预览完成后要调用URL.revokeObjectURL(url)。如果列表页连续选择几十张大图，不释放临时URL，浏览器内存会缓慢上升。小文件不明显，大文件或长时间后台页面会把问题放大。
用法三：接收接口文件流
在axios或fetch里下载文件，Blob的优势更直接。fetch可以用response.blob()，axios则常设responseType为'blob'。得到Blob后，根据Content-Disposition解析文件名，再触发下载。这个流程适合PDF、Excel、ZIP等文件。
需要权衡的是错误处理。接口成功时返回文件流，失败时可能返回JSON错误信息。如果前端一律按Blob下载，用户会得到一个打不开的文件。更稳的做法是判断Content-Type：若是application/json，先把Blob转文本并解析错误；若是目标文件类型，再下载。
用法四：上传和分片处理
Blob有slice方法，这让它适合做大文件分片上传。以100MB视频为例，可以按5MB一片切分，再逐片上传。正面是失败后可重传部分片段，服务端也便于断点续传；反面是实现复杂度提高，需要处理分片编号、校验值、合并状态和重试策略。
实际项目里，我更建议先确认业务是否真的需要分片。10MB以内的普通附件，直接FormData上传更省事；超过几十MB、网络环境不稳定、上传耗时明显时，再引入Blob slice才更合理。
总结：先看场景再写代码
blob怎么用，本质上是三类操作：构造文件、预览文件、传输文件。它的优点是浏览器原生支持、处理二进制数据自然、比base64更适合大文件；限制是生命周期需要管理，错误响应要识别，旧环境兼容要测试。
我的实测结论是：小型文本导出、图片预览、文件流下载可以优先用Blob；长期存储、复杂编辑、数据库式查询则不该交给Blob。把边界划清，Blob会很稳；边界模糊，它就容易变成难排查的内存和兼容问题。
推荐阅读
常见问题
- blob怎么用来下载文件？
- 用new Blob包装内容，URL.createObjectURL生成临时地址，再创建a标签设置download并点击。下载后调用URL.revokeObjectURL释放资源。
- Blob和File有什么区别？
- File继承自Blob，除了二进制内容，还带有文件名、最后修改时间等信息。用户选择的本地文件通常是File对象。
- Blob预览图片会不会占内存？
- 会。createObjectURL生成的地址需要手动释放。预览列表、批量上传、大图场景尤其要在图片卸载或替换时调用revokeObjectURL。