不能直接用 url.createobjecturl 包整个千万行字符串或巨型 uint8array，否则会因深拷贝和强引用导致内存溢出；必须分块构造 blob、流式写入、及时 revoke，推荐每块 1–4 mb 并用 textencoder 编码。
createObjectURL 导出大文件会直接崩内存？
不能直接用 URL.createObjectURL 包整个千万行字符串或巨型 Uint8Array——浏览器会把全部数据拷贝进内存并维持引用，极易触发 OOM（RangeError: Maximum call stack size exceeded 或直接卡死标签页）。真正能落地的方案，是配合 Blob 分块构造 + 流式写入逻辑，让 createObjectURL 只指向一个「轻量代理」。
千万级数据必须分块生成 Blob，不能一次性 new Blob()
一次性传入超大数组给 new Blob([hugeArray]) 会触发 V8 内部深拷贝，实测 500 万行 CSV（约 500MB 原始字符串）在 Chrome 下直接拒绝分配。正确做法是：按行/按字节切片，逐段压入 Uint8Array 或 TextEncoder.encode() 编码后的 buffer，再用 new Blob(chunks, {type: 'text/csv'}) 合并。
- 每块控制在 1–4 MB（如
encoder.encode(row).buffer累积到 2MB 就 push 进chunks数组） - 避免用字符串拼接：用
TextEncoder直接编码 UTF-8 字节，省去 JS 字符串内存开销 - 导出前不保留原始数据引用：处理完一批就
rows.splice(0, batchSize)或用迭代器消耗
createObjectURL 后必须手动 revoke，否则内存泄漏
URL.createObjectURL(blob) 返回的 URL 是强引用，Blob 不会被 GC 回收，哪怕 DOM 中已无 <a href></a> 引用它。千万级导出若频繁调用且不释放，几分钟内内存占用飙升数 GB。
- 下载触发后立刻调用
URL.revokeObjectURL(url)，推荐放在<a>.onclick</a>或fetch().then()的最终回调里 - 不要等
click事件结束：用户可能取消下载、关闭标签页，需加setTimeout(() => URL.revokeObjectURL(url), 100)保底 - 注意兼容性：Safari 15.4+ 才支持对大型 Blob 的高效
revoke，旧版建议导出后强制blob = null
替代方案：Stream API + WritableStream 更稳但兼容性差
Chrome 109+ / Edge 109+ 支持 WritableStream 直接写入 Blob，可彻底避开内存峰值，但 Safari 和 Firefox 当前不支持。如果目标环境可控，可用：
const writable = new WritableStream({
write(chunk) {
// chunk 是 Uint8Array，直接 append 到内部 buffer
}
});
// 然后 pipeThrough 转成 Blob
否则老老实实用分块 Blob + createObjectURL，这是目前唯一全平台可行的纯 JS 千万级导出路径。关键不是“能不能”，而是“怎么切得足够细、放得足够快”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
