blob测评：避坑流程清单
blob测评不能只看代码能否跑通，还要按真实流程检查文件类型、内存释放、错误响应和浏览器差异。很多问题在小样例里不出现，一到生产环境的大文件、慢网络、中文文件名，就会暴露出下载异常或预览卡顿。
步骤一：先确认数据来源
做blob测评，第一步不是写new Blob，而是确认数据从哪里来。来源通常有三类：用户本地选择的File、接口返回的文件流、前端临时生成的字符串或ArrayBuffer。正面看，三类都能被Blob承接；反面看，它们的风险点完全不同。
本地File要关注大小和格式，接口文件流要关注响应头，前端生成内容要关注编码。把这三类混在一起测，会导致结论失真。比如CSV乱码不是Blob失败，往往是字符集或Excel识别问题；PDF打不开也可能是接口返回了JSON错误。
步骤二：检查type是否准确
Blob构造时的type不是装饰字段，它会影响浏览器预览和部分应用识别。例如PDF应使用application/pdf，CSV可用text/csv;charset=utf-8，PNG图片应为image/png。type缺失时，浏览器有时仍能猜中，但这不应作为生产依赖。
避坑点在于不要机械复制'application/octet-stream'。它适合强制下载，但不适合预览。测评时应分别验证预览型文件和下载型文件：前者看浏览器是否正确打开，后者看系统应用是否能识别。
步骤三：验证中文与特殊文件名
很多blob测评只测英文文件名，这会漏掉中文、空格、括号、百分号等问题。前端download属性能设置文件名，但如果文件名来自后端Content-Disposition，还要处理URL编码、RFC 5987格式和不同浏览器解析差异。
稳妥做法是准备一组样本：report.xlsx、销售报表.xlsx、2025 Q1(终版).pdf、a%b.csv。正面看，测试成本不高；反面看，若上线后才发现乱码文件名，用户会认为导出功能不可靠。
步骤四：观察内存和释放
Blob相关问题里，最隐蔽的是内存。createObjectURL生成的临时地址不会自动立即释放，页面长时间运行时尤其明显。测评时可以在Chrome Performance或任务管理器中观察内存变化，连续预览大图或下载大文件后再关闭预览。
正确流程是：生成URL、使用URL、在不需要时revokeObjectURL。不要在图片还未加载完成前立刻释放，否则会出现偶发空白；也不要永远不释放，否则后台系统开半天后会变慢。这个平衡点比代码本身更重要。
步骤五：模拟失败响应
文件下载接口失败时，后端常返回JSON：比如权限不足、参数错误、任务未完成。如果前端responseType设为blob后不再判断，用户会下载到一个很小的错误文件。这个坑在blob测评里必须单独测。
建议检查Content-Type和文件大小。若Content-Type包含application/json，可以用await blob.text()读取错误信息；若是目标文件类型，再走下载。正面是体验清晰，反面是代码多几行，但这是生产级下载功能的基本成本。
步骤六：做浏览器回归
最后一步是浏览器回归。现代Chrome、Edge、Firefox对Blob支持较好，Safari在下载行为、内存释放时机、移动端预览上更容易出现差异。测评不能只在开发者自己的主浏览器完成。
结论要按业务用户分层：如果用户主要在企业PC端，重点测Edge和Chrome；如果有iPad或iPhone访问，Safari必须纳入。Blob本身是成熟API，但文件交互牵涉浏览器、安全策略和系统应用，单点测试不够。
推荐阅读
常见问题
- blob测评主要看哪些指标？
- 重点看文件能否正确打开、文件名是否正常、中文编码是否稳定、大文件是否卡顿、临时URL是否释放、接口错误能否被识别。
- 为什么Blob下载的是损坏文件？
- 常见原因是接口实际返回JSON错误、responseType设置不对、type不匹配、后端文件流被拦截或内容被二次编码。应先检查响应头和文件大小。
- Blob需要兼容IE吗？
- 如果业务仍支持IE，需要使用msSaveBlob等旧方案。多数现代项目可以面向Chrome、Edge、Firefox、Safari测试即可。