安全导出GB级文件的关键是避免过早创建完整Blob、及时释放URL、禁用ArrayBuffer拼接；应直接用ReadableStream构造Blob并立即revokeObjectURL。
使用 URL.createObjectURL 配合流式 Blob 导出大文件时，真正的内存风险不在于 Blob 本身，而在于**过早创建完整 Blob、未及时释放 URL 或误用内存型构造方式**。只要规避这三点，就能安全导出 GB 级文件而不卡顿或崩溃。
用 ReadableStream + Blob 构造函数替代“拼接 ArrayBuffer”
常见错误是把整个文件内容先读进内存（如用 response.arrayBuffer()），再构造 Blob——这对大文件直接 OOM。正确做法是让浏览器底层处理流，不落地内存：
- 从
fetch获取Response.body（原生ReadableStream） - 用
new Blob([stream], { type: '...' })直接包装流（Chrome 115+、Firefox 120+、Safari 17.4+ 支持） - 浏览器内部将流分块写入磁盘缓存，Blob 对象仅持有一个轻量引用
示例：
const res = await fetch('/large-report.zip');
const blob = new Blob([res.body], { type: 'application/zip' });
const url = URL.createObjectURL(blob);
const a = Object.assign(document.createElement('a'), { href: url, download: 'report.zip' });
document.body.appendChild(a);
a.click();
document.body.removeChild(a);
URL.revokeObjectURL(url); // 关键：立即释放
避免手动 chunk 拼接 ArrayBuffer（除非必须兼容旧浏览器）
若需支持老版本浏览器，必须手动读取流并分块写入 WritableStream 或 BlobBuilder，但绝不能累积所有 chunk 到一个数组里：
- 用
TransformStream实时转换，边读边写，不缓存全文 - 若用
Uint8Array数组暂存单次 chunk，每次处理完立刻丢弃引用 - 导出完成即调用
URL.revokeObjectURL，防止 URL 持有 Blob 引用导致内存无法回收
导出后务必 revokeObjectURL，且不要依赖 GC
createObjectURL 创建的 URL 是强引用，即使 Blob 变量被回收，URL 仍会阻止其释放。不 revoke 就等于内存泄漏：
- 在
a.click()后同步调用URL.revokeObjectURL(url) - 若导出失败（如用户取消保存对话框），也应在
catch或finally中 revoke - 不要等页面卸载或靠垃圾回收——它不会自动清理 object URL
补充技巧：用 download 属性绕过部分浏览器限制
某些浏览器（如 Safari）对跨域 blob URL 的 download 属性有限制。可结合以下策略提升成功率：
- 服务端设置
Content-Disposition: attachment; filename=xxx，前端直接window.location.href = '/api/export' - 若必须用 Blob，优先用
<a download>触发（比window.open(url)更可靠） - 导出前检查
navigator.onLine和存储空间（navigator.storage.estimate()），提前降级提示
