前端下载方案全解析：从a标签到Blob文件流与断点续传

做前端开发的这几年，我发现自己跟“下载”这个功能的缘分很深。小到导出一份Excel报表，大到打包一批图片、下载一套离线文档，几乎每个业务系统都躲不开这个需求。但恰恰是这种看着很简单的功能，最容易在线上翻车：要么文件名变成一串乱码，要么点击之后毫无反应，要么大文件下到一半直接卡死。也有不少读者问我，面试时总被问到“前端有哪几种下载方式”，该怎么答才能显得有水平。这篇文章我打算系统地把前端下载的几种方法、底层原理、实际代码和踩坑经验全部梳理一遍，给大家一份真正可以照着用的参考。

这个内容适合谁？如果你是刚入行、想弄懂下载功能背后机制的前端新人，可以按顺序从头读到尾；如果你是有一定经验、想查漏补缺或备战面试的开发者，可以直接跳到第三、四节看文件流下载和大文件处理；如果你今天只是线上出了个下载bug，想去目录里找排查思路，那么第五、六节可以直接用。我会用偏实战的口吻来讲，代码都是能跑的那种，不是画饼。

1. 先想清楚：前端下载到底在解决什么问题

1.1 浏览器的“默认下载”和前端能干预的部分

很多人一上来就写代码，但我觉得第一步应该先把问题定义清楚。浏览器天然就支持下载：只要用户点击一个指向资源的链接，或者直接在地址栏输入一个文件的URL，浏览器就会根据响应头里的Content-Disposition和Content-Type决定是直接展示还是下载到本地。这是浏览器的默认行为，完全不需要前端做什么。

那为什么还需要前端去“实现下载”？因为默认行为太死板了。你没法控制文件名，没法在下载前做权限校验，没法监控进度，没法断点续传，更没法在下载过程中给用户呈现一个友好的交互状态。换句话说，前端下载方案的本质，是想办法利用或绕过浏览器的默认行为，去满足业务场景的定制化需求。

我习惯把前端能控制的环节拆成三部分：触发方式（用户点击什么、怎么触发下载）、文件来源（直链、接口返回的二进制流、还是前端本地生成的内容）、下载后的反馈（成功提示、失败提示、进度展示）。后面讲到的方法，本质上都是在这三个环节上做组合和取舍。你把这个框架记在心里，面试时不管被问到哪一类下载，都能先说出它解决了哪一环节的问题，再讲具体实现。

1.2 为什么不能只靠一种下载方案

我见过不少项目，自始至终只用一种下载方式：要么全部用window.open，要么全部用a标签直链。短期看着没啥问题，等业务复杂度上来就顶不住了。

举个实际例子：用户要下载一份后台生成的报表，这个报表是接口动态生成的，URL不固定，而且接口要求带登录后的token。你直接用a标签指向一个带token的URL，很可能会因为跨域问题被浏览器拦截；如果接口返回的是二进制流、需要前端把流转成文件，那location.href也完全无能为力。再比如下载一个几十MB的安装包，你要给用户展示进度条，还用那种“点击即跳转”的原始方式，就只能看着浏览器自己的下载列表发呆，根本拿不到任何中间状态。

所以说，“前端下载的方法解释”本质上是一套按场景选型的方案清单，而不是某一段固定代码。大概的选型逻辑是这样的：静态文件直链优先用a标签，接口返回流用Blob加URL.createObjectURL，大文件要监控进度的用XMLHttpRequest或fetch加流式读取，需要断点续传的还要配合Range请求头和服务端联调。把这套逻辑想明白，比背十个下载代码片段都管用。

2. 最朴素的方案：a标签、location.href、window.open

2.1 a标签和download属性

前端下载里最基础、日常也最常用的就是a标签。正常情况下，一个<a>标签指向一个图片、PDF或压缩包地址时，浏览器会直接打开预览或跳转到对应页面，并不会触发下载。想强制让浏览器下载，关键在download属性。

html复制<a href="/files/2026/summary.pdf" download>下载年度总结</a>

加了download属性之后，浏览器会尝试把目标资源保存为本地文件。这里有个很重要的细节：download属性的值可以自定义文件名，比如download="2026年度总结.pdf"，这个值会覆盖服务端返回的文件名。但这种覆盖是有条件的，只有同源URL才能生效，跨域资源时download属性会被浏览器忽略，文件名以服务端Content-Disposition为准。这种限制不是bug，是浏览器出于安全考虑的设计：如果允许跨域页面随意给文件起名，很容易诱导用户下载并打开伪装成合法文件名的恶意内容。

实操里还有一个常见场景是点击按钮触发下载，而不是点击链接。很多人会用JavaScript模拟点击，但直接给按钮绑window.location.href会发现没法设置download属性。正确做法是在事件回调里动态创建a元素：

javascript复制function downloadByUrl(url, filename) {
  const link = document.createElement('a');
  link.href = url;
  link.download = filename;
  document.body.appendChild(link);
  link.click();
  document.body.removeChild(link);
}

这里有两个细节值得说明。第一，一定要把a元素挂到document.body上，否则在部分浏览器（尤其老版本Safari）里click()不生效；第二，点击之后要立即移除这个元素，一方面避免 DOM 冗余节点堆积，另一方面也是防止同一元素在后续交互中被误触发。我在项目里见过有人用display: none把元素隐藏起来、但一直不释放，时间长了页面上堆一堆废弃的下载节点，虽然不至于出大事，但代码review时总会被人挑毛病。

2.2 跳转式下载：location和window.open

如果不想用a标签，有时也会看到window.location.href = url或window.open(url)的方式。这种方式适合直接交给浏览器去处理下载场景，前提是服务端在响应头里已经设置了Content-Disposition: attachment。因为此时浏览器拿到响应头，就知道这是一个需要下载的文件，而不是一个需要跳转的页面。

它们的区别在于打开位置：location.href是在当前页面完成跳转/触发下载，会中断当前页面上的JS执行环境（如果是下载，当前页面不会真的跳走，但有些浏览器会闪一下）；window.open会打开一个新标签页或新窗口去发起请求。如果这个新窗口最终响应的是一个下载头，那么标签页会自动关闭，用户基本感知不到；但如果响应不是文件而是错误页面，就会留下一个空白标签页，体验很差。

我的建议是：要把这两种方式当成“备用方案”而不是“首选方案”。只有当你知道服务端一定会返回attachment、并且不需要自定义文件名、不需要监控进度时，才用它们。另外，window.open还特别容易触发浏览器的弹窗拦截。如果在异步回调里调用window.open，浏览器无法判断这是不是用户主动行为，很可能会直接拦掉。同理，location.href如果放到异步加载完成后的回调里，也可能会被部分浏览器以“非用户触达”为由阻止下载。遇到这种问题，可以先打开一个空白窗口，拿到下载地址后再设置窗口的location。

2.3 这些方案的边界在哪里

看到这里你可能会觉得，前两种方法已经能应付绝大多数页面了。我刚开始做前端时也这么想，直到遇到三个让我至今印象深刻的场景。

第一个场景：接口需要带自定义请求头（比如Authorization），而a标签和location.href根本没法设置请求头。你只能把token拼到URL查询参数里，但这么做有两个问题：一是token会出现在浏览器历史、代理日志或服务端访问日志里，存在安全隐患；二是一旦URL长度超过限制，下载直接失败。第二个场景：下载过程中需要给用户展示进度条，用a标签跳转，浏览器完全不会把进度反馈给页面。第三个场景：文件内容本身是前端动态生成的，比如前端把表格数据导出成CSV，没有现成的URL可指，必须由前端“凭空造”出一个文件来再下载。

这就引出了下一节的内容：真正支撑复杂业务场景的，是Blob配合URL.createObjectURL这套组合方案。这也是我认为前端下载里最核心、最值得掌握的方法，它的地位就好比炒菜里的“热锅凉油”，几乎每个复杂需求都绕不开它。

3. 文件流下载：Blob和objectURL才是主流

3.1 什么时候必须用Blob

Blob（Binary Large Object）是浏览器内置的二进制大对象类型，简单理解，它就是一段原始字节数据的容器。前端的Blob下载，通常出现在接口直接返回文件流的场景。后端不提供给前端一个静态下载地址，而是返回一个二进制流，由前端把它拼装成可下载的文件。

最常见的实现方式是用axios或fetch发起请求，把responseType设置为'blob'，这样响应体就是一个Blob对象。然后通过URL.createObjectURL(blob)生成一个临时的object URL，再用a标签去下载。为什么要绕这么一圈？因为Blob本身不是URL，浏览器没法直接访问它，createObjectURL的作用就是把内存中的Blob映射成一个可以访问的URL地址。这个URL以blob:开头，是内存级、会话级的，其他用户访问不到，也不会产生真实网络请求。

这里我需要强调一下，很多人会把Blob和ArrayBuffer搞混。Blob是更高层的封装，适合表示文件、图片、音视频这类内容；ArrayBuffer更底层，是固定长度的二进制缓冲区，适合做字节级的读写操作。下载场景首选Blob，除非你需要用FileReader或DataView对二进制内容做精细解析，才会用ArrayBuffer。

3.2 完整流程与核心代码

下面这段代码是我在项目里用得最多的一套下载模板，它可以处理带请求头、接口下载、进度展示三种需求：

javascript复制async function downloadFile(url, filename, options = {}) {
  const { token, onProgress } = options;
  const response = await fetch(url, {
    headers: token ? { 'Authorization': `Bearer ${token}` } : {},
  });

  if (!response.ok) {
    throw new Error(`下载失败：HTTP ${response.status}`);
  }

  const contentType = response.headers.get('Content-Type') || '';
  const blob = await response.blob();

  // 如果接口没有返回有效内容，提前返回
  if (blob.size === 0) {
    throw new Error('下载失败：文件内容为空');
  }

  // 尝试从响应头里读取服务端给的文件名
  const serverFilename = getFilenameFromContentDisposition(
    response.headers.get('Content-Disposition')
  );

  const finalName = filename || serverFilename || 'download.bin';
  triggerBlobDownload(blob, finalName, contentType);
  onProgress?.(100);
}

function triggerBlobDownload(blob, filename, mimeType) {
  const url = URL.createObjectURL(blob);
  const link = document.createElement('a');
  link.href = url;
  link.download = filename;
  if (mimeType) {
    // 有些浏览器会根据类型做额外处理
    link.type = mimeType;
  }
  document.body.appendChild(link);
  link.click();
  document.body.removeChild(link);
  // 关键：释放object URL，避免内存泄漏
  setTimeout(() => URL.revokeObjectURL(url), 1000);
}

function getFilenameFromContentDisposition(header) {
  if (!header) return null;
  const utf8Match = header.match(/filename\*=UTF-8''([^;]+)/i);
  if (utf8Match) {
    return decodeURIComponent(utf8Match[1]);
  }
  const plainMatch = header.match(/filename="?([^";]+)"?/i);
  return plainMatch ? plainMatch[1] : null;
}

这套代码看起来不复杂，但有几个细节新手很容易忽略。首先，判断response.ok很重要，因为接口返回错误时，后端往往也会返回一个JSON或空串，如果不提前拦截，前端会把错误内容误当成文件下载下来，用户拿到的就是一个打不开的垃圾文件。其次，blob.size === 0的判断要加，我在实际项目里遇到过后端逻辑异常但HTTP状态码是200的情况，导致用户下载了一个0字节的空文件，排查了半天才发现是后端的问题。第三，URL.revokeObjectURL一定要调用，但不要在click()之后立刻调用，否则某些浏览器（尤其Safari）会有概率下载失败。我习惯延迟1000毫秒释放，实测下来最稳。

3.3 文件名的正确打开方式

Blob下载最折磨人的一个问题就是文件名。URL.createObjectURL生成的URL是一串随机ID，浏览器根本不知道原文件名是什么，所以a标签的download属性成了唯一能控制文件名的地方。问题在于，这个文件名从哪来？

我总结了三个来源，优先级从高到低：前端业务逻辑指定的文件名（比如用户选择的导出类型）、接口响应头里的Content-Disposition、兜底文件名。第一种最简单，第二种需要解析Content-Disposition，但又有个历史遗留坑：老浏览器只支持filename="xxx.pdf"这种形式，中文会乱码；新标准支持filename*=UTF-8''xxx，能显式指定编码。所以解析时一定要同时兼容两种写法，我在代码里就是先匹配filename*，匹配不到再退回到普通filename。

如果你遇到中文文件名下载后乱码，排查方向基本就是这里。还有一种情况是后端返回的Content-Disposition里filename和filename*同时存在，但内容不一致，此时应当优先信任filename*。我在实际联调中就被这个坑过，后端同事在filename里写的是编码前的原始中文，在filename*里写的是编码后的结果，前端如果先取到filename就会得到一串乱码。

3.4 内存泄漏和兼容性问题

Blob下载的另一个大坑是内存与兼容性。我在写下载组件时养成一个习惯：下载完之后，必须释放object URL。原因在于URL.createObjectURL创建的URL会在浏览器内存里保留一份对应Blob的引用，如果不手动释放，即使页面已经跳转，这份内存也一直占用着。短时间下载一两个文件还好，如果用户批量下载几百个文件，内存会肉眼可见地涨上去，尤其在移动端会更明显。

兼容性方面，URL.createObjectURL在现代浏览器里支持度非常好，但在非常老的IE里不存在，而是叫window.navigator.msSaveOrOpenBlob。如果项目还要支持IE，代码得加一层降级判断：

javascript复制function triggerBlobDownload(blob, filename) {
  if (window.navigator && window.navigator.msSaveOrOpenBlob) {
    window.navigator.msSaveOrOpenBlob(blob, filename);
    return;
  }
  // 走createObjectURL逻辑
}

不过我建议如果你的项目还要维护IE的话，优先考虑引入一个成熟的下载库，比如file-saver，它把兼容性坑都处理好了，省心很多。当然，库的体积和依赖也要权衡。多数现代项目里，自己封装一段30行的下载工具函数就完全够用了。

4. 大文件下载：进度、分片、断点续传

4.1 如何拿到下载进度

如果只是下载一个小文件，点击后等浏览器自己处理就行。但面对大文件，用户会关心“下到哪了”，这时候就需要前端自己拉取文件流并监控进度。

用XMLHttpRequest是最直接的方式，因为它原生支持progress事件：

javascript复制function downloadWithProgress(url, onProgress) {
  return new Promise((resolve, reject) => {
    const xhr = new XMLHttpRequest();
    xhr.open('GET', url, true);
    xhr.responseType = 'blob';

    xhr.onprogress = (e) => {
      if (e.lengthComputable) {
        onProgress(Math.round((e.loaded / e.total) * 100));
      }
    };

    xhr.onload = () => {
      if (xhr.status >= 200 && xhr.status < 300) {
        // 这里同样要把xhr.response转成Blob后下载
        resolve(xhr.response);
      } else {
        reject(new Error(`下载失败：HTTP ${xhr.status}`));
      }
    };

    xhr.onerror = () => reject(new Error('网络异常'));
    xhr.send();
  });
}

e.lengthComputable是个关键判断。如果为true，说明服务端告诉了我们文件总大小，可以精确计算百分比；如果为false，说明服务端没返回Content-Length，进度条只能做成不确定状态。实战中，我看到很多团队前脚刚写完进度条，后脚后端接口没配Content-Length，进度条就卡住不动，还以为是前端bug。定位这个问题时，可以先打开开发者工具看响应头里有没有Content-Length字段。

如果你偏好fetch，它本身不直接提供进度事件，但可以通过response.body的ReadableStream来手动读取数据块，并在读取过程中累计字节数。这种写法代码量更大，而且要自己处理流的中断和错误，所以我个人还是建议大文件下载优先用XHR。不是fetch不够现代，而是“下载并展示进度”这个场景，XHR的事件模型更顺手。

4.2 分片下载：多线程加速

下载大文件的另一种思路是分片并发。原理很简单：前端请求文件部分内容，拿到Content-Range之后再继续请求下一部分。服务端需要支持Range请求头。

用fetch发起一段范围请求是这样的：

javascript复制async function fetchRange(url, start, end) {
  const response = await fetch(url, {
    headers: { 'Range': `bytes=${start}-${end}` },
  });
  if (response.status !== 206) {
    throw new Error(`服务端不支持Range请求，状态码: ${response.status}`);
  }
  return await response.blob();
}

分片下载通常要配合Web Worker来做，否则在主线程里并发拉多个分片，页面很容易卡顿。很多项目里做“大文件下载/上传”都会用Worker，配合热搜词里经常出现的“前端使用worker上传大文件”其实是一个思路：把耗时的二进制操作从主线程挪到后台线程。

一个简化版的分片下载思路是：先发一个不带Range的HEAD或GET请求，从Content-Length拿到文件总大小，然后切分成若干片（比如每片5MB），使用Promise.all并发拉取指定的片段，最后把多个Blob按顺序拼接成一个完整文件。拼接时要注意用new Blob([part1, part2, ...])，并且指定统一的type。这里还有个隐患：如果并发数太高，浏览器会建立很多TCP连接，可能触发服务端限流或429状态码。我建议并发数控制在4到6个，具体按网络环境调。

分片下载并不能真正提高服务器的传输带宽上限，更像是把原来的单车道变成多车道，在某些有限速或单个连接性能差的场景下有奇效。但它要求后端配合支持Range，如果服务端不认这个请求头，就会返回200和整个文件，前端拿到的状态码不是预期中的206，所以代码里一定要对这个状态做兜底处理。

4.3 断点续传：前端能做哪部分

断点续传经常被问，但很多人容易把它想得太玄乎。前端要做的其实比较明确：

1. 记录已完成的分片：把已经下载下来并验证过的分片信息（起始字节、长度、结束字节等）保存到localStorage或IndexedDB。
2. 中断后重新发起：再次下载时，通过Range请求头请求未完成的部分，跳过已经下载的分片。
3. 合并和校验：全部下载完成后，把分片合并成完整文件，可以用文件总大小或者服务端提供的ETag/Content-MD5做完整性校验。

这里最大的坑在于：服务端必须支持Range请求，且前端无法控制文件在磁盘上的位置。浏览器出于安全考虑，一般不允许网页脚本直接写本地磁盘文件（File System Access API除外，且权限要求较高），所以断点续传在普通网页环境下更多是“断点续传下载，但最终拼接在内存里完成”，文件特别大时仍然有内存压力。

如果你想实现更彻底的断点续传，可以考虑用File System Access API里的showSaveFilePicker，在用户授权后拿到一个可写的文件句柄，把分片数据直接写入磁盘。这个API在Chrome和Edge里支持度不错，但在Firefox和Safari里还不行。做内部系统时可以用它，对外产品要谨慎，必须做能力检测和降级方案。

5. 工程师视角的避坑清单

5.1 跨域下载怎么处理

下载踩坑排行榜第一位，我认为是跨域。很多场景下，文件存储在CDN或独立的文件服务上，和前端页面不同源。这时候用a标签会碰到几个问题：

• download属性在跨域场景下会失效，浏览器忽略自定义文件名。
• window.open或location.href虽然能触发下载，但同样不能控制文件名。
• fetch或XHR拉取跨域文件流时，要求服务端正确返回Access-Control-Allow-Origin等CORS头，否则JS根本读不到响应。

针对跨域下载，我梳理出两条可行路径：

路径一：前端只做触发，文件名交给服务端。用a标签指向文件URL，后端在响应头里写好Content-Disposition: attachment; filename="xxx"。前端别想着自定义文件名，直接让浏览器按服务端给的名字下载。简单可靠，是最推荐的方式。

路径二：后端做代理转发，把跨域请求变成同源请求。前端请求自家后端接口，后端去文件服务拉取数据并返回给前端，前端再用Blob去下载。这种方式前端体验最好，还能在下载前做权限校验，缺点是要占后端带宽和内存。

还有一种偏门方式是用fetch加mode: 'cors'拉取文件，前提是服务端允许跨域。拉回来后用Blob下载，文件名就能由前端控制。但这个方法受CORS策略限制，很多文件服务并不会给所有域开放权限，所以我不建议把它当默认方案，最多在内部系统里用。

5.2 文件名乱码和格式错误

文件名乱码的根因，绝大多数是编码解析不一致。比如服务端在Content-Disposition里用的是filename*=UTF-8''，前端解析时没有decodeURIComponent，拿到的自然是一串百分号编码。反过来，如果服务端只给了filename，里面直接放中文，但HTTP头默认编码是Latin-1，中文字符可能已经变成乱码，前端怎么解析都救不回来。

所以遇到乱码问题，我建议先抓包看响应头原文，确认服务端到底发的是什么格式，再决定前端怎么解析。如果服务端用的是老式的filename直接放中文，最好的办法是推动后端改成RFC 5987规范的filename*=UTF-8''格式，这属于标准做法，后端同事一般也愿意配合。

另外，文件格式错误的问题也经常出现。最常见的是把JSON或错误信息当成文件内容下载了，用户下载下来的文件打开全是乱码或一段报错文本。这种问题我在前面已经强调过：一定要先检查response.ok和blob.size。还有一个隐蔽问题：有些后端会把PDF、Excel等文件流读取后，没有正确设置Content-Type，前端创建Blob时也没指定type，导致下载的文件没有正确的MIME类型，在手机上打开时会被识别成未知文件。处理方式是优先读响应头的Content-Type，并在创建Blob时显式传入：

javascript复制const blob = new Blob([data], { type: contentType });

5.3 内存泄漏、重复触发和按钮状态

我在代码review时经常看到三个问题，这里集中说一下。

第一个是object URL不释放。前面讲过，下载完成或下载失败后，都要调用URL.revokeObjectURL。我见过有同事把下载函数封装到工具里，但忘了释放，导致批量下载时页面越来越卡。解决方式很简单：在triggerBlobDownload的setTimeout里统一释放，或者用try/finally保证无论成功失败都释放。

第二个是重复点击。下载是异步操作，用户等得不耐烦就会狂点按钮，结果同时发起了好几个请求。这在小文件场景下影响不大，但大文件下载时会严重影响服务端压力。我的习惯是在点击后立即将按钮置为disabled并显示“正在准备下载”状态，下载结束或失败后再恢复。

第三个是生命周期竞态。在React或Vue单页应用里，如果用户点击下载后快速切换到其他页面，异步请求回来时组件可能已经卸载。此时如果再操作DOM或更新状态，轻则报警，重则崩溃。处理方式是使用AbortController，在组件卸载时abort掉未完成的下载请求，或者在状态更新前判断组件是否仍然挂载。前者更彻底，我推荐在需要用fetch下载的大文件场景里都加上。

另外，对下载按钮的UI状态也要设计好：等待时、下载中、成功、失败，这四个状态最好都有对应提示。不要出现用户点了没反应的情况，那是最伤体验的。

5.4 下载进度和服务器支持情况

最后再补充一个进度相关的坑。前端展示了进度条，但如果服务端没有返回Content-Length，或者接口使用了Transfer-Encoding: chunked，前端拿不到总大小，进度条就永远算不出百分比。有些团队会把这种进度条做成“转圈菊花”，其实也算一种处理，但不能展示真实进度。

如果是自己控制的后端，我建议下载接口务必返回准确的Content-Length。尤其是那些用Node.js做的文件服务，如果用了res.end(buffer)这种方式，只要buffer是一次性写入，Node一般会自动带上Content-Length；但如果用流式pipe且没设置长度，就会变成chunked传输，前端进度就不好算了。所以联调时多问一句“响应头里Content-Length有没有”，能省很多事。

6. 面试与工程中的高频问题速查

6.1 面试高频考点

前端面试很爱考下载相关的题目，而且出题角度五花八门。结合我最近的面试复盘和读者反馈，整理了几个比较有代表性的：

Q1：a标签的download属性有什么限制？
基础答法是“可以指定下载文件名”。加分的答法是点出跨域限制：不同源的资源，download属性不生效，文件名由服务端Content-Disposition决定；还要提到它不能自定义请求头，无法用于需要鉴权的接口下载。

Q2：怎么下载一个接口返回的二进制流？
要点是设置responseType: 'blob'，拿到Blob后用URL.createObjectURL生成临时URL，再通过a标签触发下载。别忘了判断响应状态、检查空文件、释放URL。面试官如果追问进度条，就补上XHR的progress事件或fetch的ReadableStream读取方案。

Q3：前端怎么实现断点续传下载？
好的回答结构是：先说服务端要支持Range请求头；然后说前端需要用Range: bytes=start-end拉取分片数据，记录已下载范围；中断后从断点继续拉取；最后把分片合并，再做完整性校验。如果能提到File System Access API写磁盘的限制，会更有深度。

Q4：下载文件名中文乱码怎么解决？
答案要落到编码上：优先解析filename*=UTF-8''，兼容老式的filename；前端要正确解码，后端要遵循RFC 5987规范。还可以讲一下解析Content-Disposition的完整兼容逻辑。

面试这种题目，重点不是背代码，而是把“为什么”讲明白。比如为什么跨域就不能用download改名，为什么Blob下载后要revokeObjectURL。把原理理解透了，随口都能答出细节，比背八股文管用。

6.2 常见问题排查思路

在实际开发里，遇到下载问题不要慌，我一般按这个顺序排查：

这套排查表更像是我自己的“肌肉记忆”，每个问题背后都对应一个真实的线上事故。我踩过最深的坑就是“下载下来文件打不开”，查了整整一个下午，最后发现是后端返回了登录超时的JSON，而前端把200当作成功处理，直接生成一个.csv文件下载了。那次之后我就把response.ok和内容判断写进了所有下载工具函数，再也没犯过同样的错。

7. 最后的经验分享

如果你问我现在做一个下载功能，会怎么选型，我的大概思路是：静态资源直链，直接用a标签，文件名交给服务端；需要鉴权或动态生成的文件，优先考虑fetch加Blob下载；需要进度条，切到XHR；文件特别大或需要断点续传，就跟后端确认Range支持情况，再上分片和Worker方案。

有一点我想多说一句：前端下载方案很难脱离后端环境单独成立，编码格式、跨域策略、Content-Length、Range支持，每一个都牵扯到服务端的行为。所以遇到下载问题，不要只盯着前端代码，多和后端同事对齐响应头和接口约定，很多问题能提前避免。

最后再分享一个我一直在用的小技巧：把下载工具函数统一封装到一个模块里，所有项目复用。不要每个页面都自己写一遍下载逻辑，那样很容易出现“这个页面释放了URL，那个页面没释放”的混乱局面。好的封装能让团队少踩很多坑，这也是我维护前端工具库多年最深的体会。