Chrome下载大文件易崩溃的根本原因是传统Blob方式将整个文件加载进内存，而Service Worker可拦截响应流并直写硬盘。它通过ReadableStream与WritableStream绕过JS堆，避开V8内存限制；需HTTPS/localhost注册，刷新生效，配合StreamSaver.js实现流式下载。
Chrome下载大文件容易崩溃，根本原因在于传统方式要把整个文件加载进内存再生成 Blob，而 Chrome 对单个 Blob 的实际承载能力通常卡在 1–2GB 左右。真正可行的解法不是“让内存更大”，而是绕过内存——用 Service Worker 拦截响应流，把数据像自来水一样直接导进用户硬盘。
为什么必须用 Service Worker？
普通前端脚本运行在渲染进程里，所有 fetch 响应体默认先存进内存；而 Service Worker 是独立线程，能拿到原始 ReadableStream，并通过 WritableStream 直接对接操作系统文件系统（经由 StreamSaver.js 封装）。它不经过 JS 堆，也就避开了 V8 内存上限和 Chrome 主动 kill 进程的机制。
关键点：
- Service Worker 必须在 HTTPS 或 localhost 下注册，否则浏览器拒绝安装
- 注册后不会立即接管当前页面，需刷新或新开标签页才能生效
- 拦截的是 fetch 请求（包括 window.fetch、XMLHttpRequest、img/script/link 标签等），但不能拦截 iframe src 或 location.href 跳转
核心流程：从请求到落盘
整个链路由三部分协同完成：前端发起、Service Worker 拦截、StreamSaver 写盘。
前端只需做两件事：
- 调用 StreamSaver.createWriteStream(filename)，它会返回一个 WritableStream，并自动触发 Service Worker 注册与通信
- 用 fetch 获取大文件流，通过 response.body.pipeTo(writable) 把响应体直连写入磁盘
Service Worker 端要做的，是监听特定路径（比如 /streamsaver-download）的 fetch 请求，然后返回一个空响应（status: 200）并附带 Content-Disposition: attachment，这样浏览器才会弹出保存框。真正的数据流并不走这个响应体，而是由 StreamSaver 在后台通过 postMessage 与 SW 通信，建立流通道。
常见陷阱与应对
实际落地时，这几个问题最容易导致失败：
-
跨域请求被拦截：fetch 必须是同源，或服务器明确返回
Access-Control-Allow-Origin: *和Access-Control-Allow-Headers: Range，否则流式读取会中断 - 未正确处理 Range 请求：如果后端支持断点续传，Service Worker 需透传 Range 头并返回 206 Partial Content；否则强制设为 200 并忽略 Range
- 文件名中文乱码：不要依赖后端 header 中的 filename，改用前端 createWriteStream 传入的 filename 参数；推荐用 encodeURIComponent 编码，再在 SW 中 decodeURIComponent 还原
-
移动端兼容性差：iOS Safari 完全不支持 StreamSaver，Android Chrome 80+ 支持良好；需提前检测
'WritableStream' in window并降级为传统 Blob 下载
轻量级验证方法
不用写完整项目，也能快速验证是否走通流式路径：
- 打开 DevTools → Application → Service Workers，确认 SW 状态为 “Activated” 且 “Clients” 显示当前页面
- 在 Network 面板中过滤
streamsaver或查看 fetch 请求的 Initiator 是否为sw.js - 下载过程中观察 Memory 面板：JS Heap 应基本平稳（
- 下载开始后立刻关掉网络，文件仍能继续写入——说明数据已脱离网络依赖，真正“边下边存”
