前端下载方案全解析：从a标签到流式分片与Worker实践

前端下载这件事，看起来简单，真做起来坑比想象中多。很多人第一次接手“导出Excel”“下载压缩包”这种需求时，第一反应就是window.open(url)或者扔个<a href="xxx">就完事，结果在线上遇到跨域失效、文件名乱码、大文件卡死、内存爆掉各种问题，最后回过来补课才发现，前端下载背后藏着浏览器安全策略、Blob内存模型、流式写入这些硬核知识点。

这篇文章我把这些年用过的前端下载方案整个梳理一遍，从最基础的a标签一直到Web Worker并发分片下载，每个方案不光给代码，还把“为什么这么写”“什么时候该用哪个”讲清楚。无论你是刚入行的前端，还是准备面试想补下载相关八股文，或者正在做一个要处理大文件下载的项目，这篇都能直接拿来当参考。

1. 前端下载的整体思路与方案选型

1.1 先搞清楚“前端下载”的本质

前端下载本质上就两件事：拿到文件数据，再触发浏览器把它存到磁盘。但这里有个容易被忽略的前提——浏览器出于安全考虑，不会让我们随便往用户磁盘里写文件。所以前端能做的，要么是“引导浏览器自己下载”（比如跳转或者点链接），要么是“把数据拿到内存里，加工成浏览器认的格式，再引导下载”。

搞清楚这个本质，后面所有方案就都串起来了。像window.open和location.href走的是第一种，浏览器直接发起导航请求；而fetch拿数据、转Blob、生成URL再触发a标签，走的是第二种。很多同学不理解为什么window.open('http://xxx/file.zip')明明能下载，改成fetch转blob反而出问题，其实就是没有理解这两条路的差异。

另外还得提一嘴“浏览器如何处理文件响应”。当服务端返回一个文件时，浏览器先看Content-Type，再看Content-Disposition。如果返回的是application/octet-stream并且带上Content-Disposition: attachment; filename="xxx"，浏览器直接进入下载流程，这个叫“服务端兜底”。前端能优化的，更多是文件名控制、进度提示、大文件处理这些体验层面的东西。

1.2 各方案横向对比与选型建议

我用一个表格先把主流方案摆出来，方便你快速定位自己该用哪个。

表格里最常用的是前三个。我自己的选型经验是：静态资源下载优先用a标签，要带授权信息或者POST提交的用fetch转Blob，超过200MB的文件再考虑流式或分片，否则别为了炫技把简单需求复杂化。

2. 最基础的 a 标签下载与 download 属性拆解

2.1 标准写法与同源限制

先看最经典的一段代码：

html复制<a href="/uploads/report.pdf" download="季度报告.pdf">下载报告</a>

这段代码在“同源”情况下完全没问题，download属性会把目标文件下载下来，并且文件名改成季度报告.pdf。但一旦文件是跨域的，比如href指向https://cdn.another-site.com/report.pdf，你会发现download属性直接失效，浏览器照样打开预览而不是下载，或者下载了但文件名还是服务端返回的。

原因是浏览器规范里明确说了，download属性只在同源URL、blob:、data:协议下生效。这是安全设计，防止恶意网站诱导用户下载任意文件并伪装文件名。遇到跨域资源又想控制文件名，就只有一条正道——先fetch拿到数据，转成blob，生成本地对象URL再挂到a标签上，这样download又生效了，因为此时href是同源的blob:链接。

还有一个实操细节：动态创建a标签触发下载后，记得把节点从DOM里移除，同时释放URL.createObjectURL生成的对象URL，不然长时间运行会有内存泄漏。我见过有项目在循环下载几百个文件时，页签直接崩了，最后定位就是revokeObjectURL没做。

2.2 跨域下载的三种绕法

跨域文件下载，我整理一下实际可用的三条路：

• 服务端配合，加响应头：让服务端在响应里带上Content-Disposition: attachment; filename="xxx"，这时即使前端只用window.open，浏览器也会下载，文件名由服务端定。这是最省事的方案。
• 前端代理转发：让后端写一个转发接口，前端请求同源接口，后端去拉取跨域文件再返回。好处是彻底绕开跨域，缺点是增加服务端带宽和延迟。
• 前端fetch + blob：前端直接用fetch请求跨域文件，前提是目标服务器允许CORS。拿到数据后转blob，再用URL.createObjectURL生成本地链接，最后用a标签触发下载。这个方案能完全控制文件名，但大文件有内存压力。

注意，现代浏览器中fetch对no-cors模式的响应体是opaque，你是读不到数据的，更没法转blob。所以跨域下载想走后端就加CORS，不想加CORS就别折腾fetch了，老老实实让用户点链接跳转。

3. Blob 与 Data URL 下载：小文件利器，大文件天坑

3.1 两者原理与差异

Blob和DataURL都能把字节数据变成一个可以被a标签引用的地址，但底层差别很大。

URL.createObjectURL(blob)是浏览器在内部维护的一个引用地址，类似blob:http://localhost:8080/xxxx-xxxx，它指向内存中的Blob对象本身。整个过程没有复制数据，性能很好，生成URL几乎是瞬间完成的。但注意，这个URL只在当前页面会话内有效，刷新页面就失效。

FileReader.readAsDataURL(blob)则是把文件内容用Base64编码读成一长串字符串，类似data:application/pdf;base64,JVBERi0xLjQK...。浏览器解析这个字符串时，需要重新解码成原始字节。Base64编码本身会膨胀约33%，而且JS字符串在内存里是UTF-16编码，所以一个100MB的文件，读成DataURL之后，字符串占用的内存基本上是100MB * 1.33 * 2，也就是接近270MB，再加上原始Blob的100MB，轻轻松松破300MB。

实际操作中我强烈建议：能用createObjectURL就别用FileReader。只有在兼容老IE、或者某些极端场景确实需要data:协议内嵌文件的时候再考虑FileReader。

3.2 内存占用的真实计算

我实际测过一个120MB的PDF转成DataURL，页签内存占用从大概80MB涨到了450MB，页面开始有明显卡顿。这个体验是没法接受的。

所以我的建议分档：50MB以下的文件，闭着眼睛用fetch + blob + createObjectURL；50MB到200MB之间，可以在下载前给个loading提示，同时用revokeObjectURL及时释放内存；超过200MB，别再用“整包拿”的思路了，优先让服务端直接返回下载链接，或者上流式和分片方案。

4. 大文件流式下载与分片方案

4.1 StreamSaver 的 Service Worker 原理

大文件下载的核心痛点就是内存。你没办法把2GB的压缩包全塞进内存再转blob，浏览器会直接崩溃。这时候需要把“同时只保留一小块数据在内存里”，边下载边写盘，这就是流式下载。

前端目前比较成熟的方案是StreamSaver库，它背后的原理是：

1. 页面在开始时通过streamsaver库注册一个Service Worker。
2. 页面拿到一个MessageChannel，然后调用streamSaver.createWriteStream('文件名')得到一个可写流。
3. 之后的下载请求通过fetch拿到ReadableStream，用管道把数据块pipeTo到可写流。
4. Service Worker那边拦截浏览器对blob: URL的请求，把可写流里的数据一片一片写进磁盘。

为什么要绕这么一大圈？因为浏览器没有直接给网页暴露“写文件到磁盘”的API，Service Worker是唯一一个能拦截浏览器导航请求并返回自定义流的东西。StreamSaver就是利用这个机制，做了一个“下载代理”。同时因为每片数据写入磁盘后就释放了，内存不会随着文件大小增长，这是它最大的价值。

代码上手大概这样：

javascript复制import streamSaver from 'streamsaver';

const fileStream = streamSaver.createWriteStream('big-file.zip', {
  size: 1024 * 1024 * 1024, // 可选，预估总大小
});
const response = await fetch('/download/big-file.zip');
const readableStream = response.body;

if (window.WritableStream && readableStream.pipeTo) {
  await readableStream.pipeTo(fileStream);
}

要注意兼容性。Service Worker本身不是什么新鲜东西，但WritableStream在部分旧浏览器上不支持，需要做降级方案。我的做法是先判断window.WritableStream，不支持就回退到fetch + blob + 下载，虽然内存扛不住，但至少功能可用。

4.2 基于 Range 的分片下载与进度计算

分片下载的思路是：服务端支持Range请求时，前端把一个大文件拆成多个片段，并发请求/file.zip的不同字节区间，最后再把所有片段合并成一个Blob触发下载。

服务端是否支持Range，可以用fetch发一个HEAD请求看响应头里有没有Accept-Ranges: bytes。确认支持后，就能指定Range: bytes=0-1048575这种头去请求某个片段。

一个简化版的分片下载核心代码：

javascript复制async function downloadRange(url, start, end) {
  const res = await fetch(url, {
    headers: { Range: `bytes=${start}-${end}` },
  });
  return await res.arrayBuffer();
}

async function downloadWithChunks(url, chunkSize = 4 * 1024 * 1024) {
  const headRes = await fetch(url, { method: 'HEAD' });
  const total = Number(headRes.headers.get('content-length'));
  const chunks = [];
  
  for (let i = 0; i < total; i += chunkSize) {
    const start = i;
    const end = Math.min(i + chunkSize - 1, total - 1);
    chunks.push(downloadRange(url, start, end));
  }
  
  const buffers = await Promise.all(chunks);
  const blob = new Blob(buffers, { type: 'application/octet-stream' });
  const link = document.createElement('a');
  link.href = URL.createObjectURL(blob);
  link.download = 'file.zip';
  link.click();
  URL.revokeObjectURL(link.href);
}

这个方案能跑通，但有两个隐藏问题值得注意。

第一个是并发数。上面代码里用Promise.all一口气发几十个请求，浏览器对同一域名的并发连接数有限制（一般是6个左右），多余的请求会排队，不会更快，反而可能影响其他资源加载。我实际用的策略是控制并发在3到5个，用一个简单的任务队列去调度。

第二个问题是内存。所有的arrayBuffer最后都要汇总成一个大Blob，这本质上还是把整个文件放进了内存。也就是说，分片下载解决了“并发加速”和“断点续传”的潜力，但没有解决内存占用。如果文件真的特别大，还是得配合“边下载边写盘”的StreamSaver思路，或者直接放弃前端拼接，改用服务端返回下载链接。

5. Web Worker 辅助下载：把IO和拼接扔到后台

5.1 Worker 分片下载的完整实现

前端下载过程中最影响体验的其实是两件事：网络请求和文件拼接。如果这些都在主线程做，UI会掉帧，用户点个下载按钮后页面像死了一样。Web Worker就是解决这个问题的，它能在后台线程里跑HTTP请求、做分片下载和拼接，主线程只负责展示进度和收结果。

先看主线程这边的代码：

javascript复制const worker = new Worker('/download-worker.js');

worker.onmessage = (e) => {
  if (e.data.type === 'progress') {
    // 更新进度条
    updateProgress(e.data.loaded, e.data.total);
  } else if (e.data.type === 'done') {
    const { blob, fileName } = e.data;
    const url = URL.createObjectURL(blob);
    const a = document.createElement('a');
    a.href = url;
    a.download = fileName;
    a.click();
    URL.revokeObjectURL(url);
    worker.terminate();
  }
};

worker.postMessage({
  type: 'start',
  url: '/download/big-file.zip',
  fileName: 'big-file.zip',
  chunkSize: 8 * 1024 * 1024,
  concurrency: 3,
});

再看download-worker.js：

javascript复制let total = 0;
let loaded = 0;
let activeRequests = 0;
const pendingRanges = [];

async function fetchHead(url) {
  const res = await fetch(url, { method: 'HEAD' });
  return Number(res.headers.get('content-length'));
}

async function fetchRange(url, start, end) {
  const res = await fetch(url, {
    headers: { Range: `bytes=${start}-${end}` },
  });
  return await res.arrayBuffer();
}

self.onmessage = async (e) => {
  const { url, fileName, chunkSize, concurrency } = e.data;
  total = await fetchHead(url);
  
  const chunks = [];
  for (let start = 0; start < total; start += chunkSize) {
    const end = Math.min(start + chunkSize - 1, total - 1);
    pendingRanges.push({ start, end });
  }

  await new Promise((resolve) => {
    const startNext = async () => {
      if (pendingRanges.length === 0) {
        if (activeRequests === 0) resolve();
        return;
      }
      activeRequests++;
      const range = pendingRanges.shift();
      const buffer = await fetchRange(url, range.start, range.end);
      chunks.push({ index: range.start / chunkSize, buffer });
      loaded += buffer.byteLength;
      self.postMessage({ type: 'progress', loaded, total });
      activeRequests--;
      startNext();
    };

    for (let i = 0; i < concurrency; i++) startNext();
  });

  chunks.sort((a, b) => a.index - b.index);
  const blob = new Blob(chunks.map(c => c.buffer), { type: 'application/octet-stream' });
  self.postMessage({ type: 'done', blob, fileName });
};

这段代码里有一个关键点：我把分片数据通过postMessage传回主线程，但主线程收到的blob是Worker里创建的Blob对象，再通过结构化克隆传给主线程。这里实际上存在一次数据拷贝。如果你要传递的是ArrayBuffer，可以用Transferable对象转移所有权，避免拷贝。

5.2 并发策略与内存回收技巧

Worker里并发下载的时候，并发数是一个需要反复调的值。并发太高，浏览器网络层排队和TCP连接管理会拖慢速度；并发太低，大文件下载慢得让人着急。我在项目里试过1到8个并发，经验值是在普通宽带环境下3到5个并发收益最明显，超过5个提升很小，因为带宽成了瓶颈。

内存回收方面有几个细节：

• Worker内部分片下载时，每一片arrayBuffer都会占内存。如果下载5GB的文件，分片全部堆积在Worker里，内存照样会爆。所以对超大文件，更合理的方案是“边下边写”而不是“下完再拼”。
• 主线程收到blob后，用URL.revokeObjectURL释放对象URL。
• 下载完成后调用worker.terminate()，直接杀掉Worker线程，它里面的内存会被整体回收，比在Worker里手动置空变量更彻底。
• 如果使用Transferable转移ArrayBuffer，要注意转移后原Worker里的变量不能再使用，否则会报错。

6. 高频坑位排查与避坑清单

6.1 典型问题速查表

前端下载的坑大多是重复出现的，我把实际项目中高频遇到的问题汇总成一张表，方便你排查时直接对着看。

6.2 三个值得记住的细节

第一个是“下载文件名到底听谁的”。优先级从高到低大概是：浏览器对同源a[download]的处理 > 服务端Content-Disposition的filename* > 服务端Content-Disposition的filename > URL末尾的文件名。也就是说，如果同源且你加了download属性，你写什么名就是什么名；如果跨域或者没加download，服务端响应头兜底。这个顺序搞明白了，文件名乱码的问题就很好定位。

第二个是“下载接口到底能不能用GET”。很多后端习惯把所有接口都设计成POST，导致前端只能用fetch拿二进制，然后自己转blob，这本身没问题。但有些后端返回的不是文件流，而是JSON里包了Base64字符串，前端还要先解码Base64再处理，性能比直接拿二进制差很多。这种情况下我一般会推动后端改接口直接返回文件流，或者至少返回二进制，而不是Base64字符串。

第三个是“进度条别只做假动画”。如果服务端返回了Content-Length，可以准确算进度；如果没有，fetch的chunk累计也能算。但很多接口开了Gzip，Content-Length是压缩后的长度，进度条会跳到100%后卡着不动，纠结好久才发现是网络代理或者服务端做了一层压缩传输。遇到这种情况，要么关闭传输层压缩，要么就别显示具体百分比，改成“文件较大，请耐心等待”这种状态提示，用户体验反而更稳。

另外，下载其实还有一个隐藏的兼容性方案——File System Access API。Chrome支持showSaveFilePicker直接弹系统保存对话框，把数据写入用户指定位置，这在做桌面端Web应用时体验很好，但Safari和Firefox都还没跟上，目前只能算加分项，不能当主力方案。

就我个人日常工程实践来说，90%的下载需求都可以用一个几十行的downloadFile工具函数搞定，里面做三件事：判断输入是URL还是Blob，统一转成blob URL，触发点击后立即释放对象URL；剩下10%的特殊场景再针对性上Worker、分片或StreamSaver。前端下载看着是小事，踩过的坑攒起来真能写一本书，希望这篇能让你少走几步弯路。