如何利用 URL.createObjectURL 实现前端纯 JS 导出千万级数组数据为 CSV/Excel 文件

URL.createObjectURL不能解决内存压力，仅提供Blob临时访问地址；千万级数据导出必须流式分块处理CSV（每块10–50MB）、分Sheet导出Excel（每Sheet≤50万行），并及时revokeObjectURL防泄漏。

URL.createObjectURL 本身不能直接导出 CSV 或 Excel，它只是生成一个指向内存中 Blob 的临时 URL；真正起作用的是你传给它的 Blob 内容是否合法、编码是否正确、体积是否可控。对千万级数组，盲目调用会直接卡死或崩溃。

为什么千万级数组不能直接 new Blob([JSON.stringify(data)])

浏览器在构造 Blob 前会把整个字符串加载进内存 —— 一个含 100 万行、每行 10 字段的数组，原始 JSON 字符串轻松突破 500MB；JSON.stringify 还会额外复制引用、逃逸双引号、补全引号，进一步放大内存压力。此时 createObjectURL 还没执行，JS 主线程已无响应。

• 避免一次性 JSON.stringify 或 array.join 整个数据集
• 不要把原始对象数组直接塞进 Blob 构造函数
• createObjectURL 不缓解内存压力，只解决“如何让 <a download> 指向动态内容”的问题

CSV 导出必须流式拼接 + 分块 Blob 构造

CSV 是纯文本，没有格式嵌套，适合边遍历边写入。关键不是“能不能”，而是“分多少块”和“每块多大”。实测单块 Blob 控制在 10–50MB 较稳妥（取决于用户设备内存），超过 80MB 在部分 Chromium 版本会触发 RangeError: Maximum call stack size exceeded。

• 用 for 循环代替 map + join，避免中间字符串累积
• 每处理 5 万行，就 push 一次 Uint8Array 到 parts 数组（而非拼字符串）
• 字段含逗号、换行、双引号时，必须按 RFC 4180 规则包裹双引号，并对内部双引号转义为 ""
• 最终用 new Blob(parts, {type: 'text/csv;charset=utf-8'}) 构造，不拼大字符串

const parts = [];let rowBuf = new TextEncoder().encode('col1,col2,col3n');parts.push(rowBuf);<p>for (let i = 0; i < hugeArray.length; i++) {const row = hugeArray[i];const csvRow = <code>"${row.a.replace(/"/g, '""')}","${row.b.replace(/"/g, '""')}",${row.c}n</code>;parts.push(new TextEncoder().encode(csvRow));</p><p>if ((i + 1) % 50000 === 0 || i === hugeArray.length - 1) {const blob = new Blob(parts, {type: 'text/csv;charset=utf-8'});const url = URL.createObjectURL(blob);// 触发下载或存入 links 数组供后续清理URL.revokeObjectURL(url); // 记得及时释放！parts.length = 0; // 清空复用}}

Excel（.xlsx）无法靠纯前端流式生成，必须用 SheetJS 并限制分页

Excel 是 ZIP 容器 + XML 结构，不支持“边写边压缩”。SheetJS（xlsx 包）的 XLSX.write 默认把整张表转成二进制再打包，千万行会瞬间吃光内存。唯一可行路径是：分 Sheet 导出，每 Sheet 控制在 50 万行以内，并禁用样式、公式、图片等任何非必要字段。

立即学习“前端免费学习笔记（深入）”；

• 启用 cellDates: false, dateNF: undefined 避免日期序列化开销
• 用 cellFormula: false 关闭公式解析（否则会递归计算依赖）
• 务必设置 bookType: 'xlsx' 和 type: 'array'，避免生成 Base64 字符串中间态
• 每生成一个 worksheet，立即调用 XLSX.utils.aoa_to_sheet 并追加到 workbook.Sheets，而不是攒满再转

注意：URL.createObjectURL 接收的必须是 Uint8Array，所以最后一步是 const buf = XLSX.write(wb, {type: 'array'}); const blob = new Blob([buf], {type: 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet'});。

URL.createObjectURL 的生命周期和内存泄漏风险

每次调用都会在浏览器内存中保留一份 Blob 引用，直到显式调用 URL.revokeObjectURL(url) 或页面卸载。导出过程中若频繁创建又不释放，几轮下来就占几百 MB —— 这比数据本身还容易导致崩溃。

• 下载链接点击后，应在 a.click() 后立刻 revokeObjectURL
• 若用 setTimeout 延迟触发下载，必须确保 revoke 不被 GC 提前回收
• 不要在 React/Vue 组件 unmount 时才统一 revoke —— 此时可能早已超时或失败
• Chrome DevTools 的 Memory 面板里搜 Blob 可快速验证是否泄漏

千万级导出不是拼技术上限，而是平衡速度、内存、兼容性和用户体验。最常被忽略的，是以为 createObjectURL 能“变出空间”，其实它只是把内存压力从 JS 堆转移到了浏览器 Blob 存储区 —— 该爆还是爆，只是时间晚一点。