根本原因不是URL.createObjectURL，而是将大字符串一次性传入Blob构造函数导致同步拷贝阻塞主线程；应改用ReadableStream+WritableStream分块写入，或Worker分片构造Blob并合并。
createObjectURL 导出大文件会卡死？根本原因不是它
直接用 URL.createObjectURL 导出几 MB 以上的 CSV，页面大概率假死——这不是 API 本身的问题，而是你把整段字符串一次性塞进了 Blob 构造函数。浏览器在生成 Blob 时会同步拷贝全部数据，内存峰值飙升，主线程被阻塞。真正该拆解的是「数据组装」和「分块写入」环节，URL.createObjectURL 只负责最后一步“挂载”，它本身极轻量。
用 ReadableStream + WritableStream 实现边生成边写入
现代浏览器（Chrome 109+、Edge 109+、Firefox 117+）已支持 WritableStream 和 TextEncoderStream，可避免拼接超长字符串。核心思路是：让 CSV 行数据作为流源，通过 TransformStream 做换行/转义处理，最终流入 new WritableStream({ write })，每写入一块就调用 controller.enqueue()。
关键点：
-
ReadableStream的pull回调里控制数据节流，比如每次只取 1000 行，防止单次 pull 过载 - 不要用
Array.prototype.join('\n')拼全部内容；改用TextEncoder.encode(row + '\n')单行编码后直接write() - 导出前先创建空
Blob，再用URL.createObjectURL(new Blob([], { type: 'text/csv;charset=utf-8' }))占位，后续流写入完成后才触发下载
兼容旧浏览器的 fallback：Worker + 分片 Blob 合并
若需支持 Safari 或老版 Chrome，不能依赖流 API。可行方案是把数据切片，在 Web Worker 中分批构造小 Blob，再用 Promise.all 并行生成所有分片的 URL.createObjectURL，最后用 new Blob([blob1, blob2, ...]) 合并——注意：合并操作仍会触发一次内存拷贝，所以单个分片建议 ≤ 2MB。
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
立即学习“前端免费学习笔记（深入）”；
常见错误：
- 在主线程里循环调用
new Blob([chunk])→ 主线程持续占用，UI 冻结 - 用
URL.revokeObjectURL过早释放中间分片 URL → 合并时 Blob 数据丢失 - CSV 字段含逗号或换行符却未加双引号包裹 → Excel 打开错列，必须在 Worker 中做严格转义
下载触发时机必须等流完全 close，否则文件截断
很多人用 URL.createObjectURL 后立刻 a.click()，但此时流可能还没写完。正确做法是监听 writable.getWriter().closed Promise，或在 WritableStream 的 close() 回调中执行下载逻辑。对于 Worker 方案，则要等所有分片 Blob 构造完成且合并完毕后再调用 createObjectURL。
容易被忽略的细节：
- 服务端返回的原始数据如果是 JSON 数组，别在主线程
JSON.parse整体 —— 改用NDJSON流式解析，或用Response.body.getReader()逐段读取 - 导出按钮点击后应禁用，防止用户重复触发；但取消操作不能只靠
revokeObjectURL，还得中断流的controller.error()或终止 Worker -
Blob的type必须显式设为'text/csv;charset=utf-8'，否则 Excel 可能误判编码，中文变乱码
