引言

在现代 Web 应用中，前端文件下载是常见的需求。根据不同的业务场景和技术要求，我们可以选择多种下载策略，主要包括直接触发下载、通过 Blob 对象下载以及通过 arrayBuffer 对象下载。理解它们的差异和适用场景对于构建高效、灵活的文件下载功能至关重要。

一. 直接触发下载

工作原理：

这是最简单直接的下载方式。前端通过创建 <a> 标签并设置其 href 属性为文件下载链接，然后模拟点击该链接来触发浏览器下载。

<a href="http://example.com/api/download/file.pdf" download="document.pdf">下载文件</a>

或使用 JavaScript：

function directDownload(url, filename) {
    const link = document.createElement('a');
    link.href = url;
    link.download = filename || 'download'; // filename 是可选的，如果服务器没有提供
    document.body.appendChild(link);
    link.click();
    document.body.removeChild(link);
}

// 示例
// directDownload('http://example.com/api/download/file.pdf', 'myDocument.pdf');

适用场景：

• 简单文件下载： 当下载的文件不需要前端进行任何处理，且服务器能够直接提供可访问的下载链接时。
• 公共文件： 下载的文件不涉及用户认证或授权，或者认证信息可以通过 URL 参数或 Cookie 自动携带。
• 后端直接控制文件名： 服务器可以直接通过 Content-Disposition 响应头指定下载的文件名。

使用差异：

• 优点： 实现简单，浏览器处理机制成熟，通常由浏览器完成进度管理和错误处理。
• 缺点：
  • 无法处理认证： 对于需要认证才能下载的文件，如果认证信息不能通过 URL 或 Cookie 传递，直接下载会比较困难（例如，需要携带请求头 Authorization 的情况）。
  • 无法获取下载进度： 前端无法直接监控下载进度。
  • 文件名控制受限： 如果后端不设置 Content-Disposition，文件名可能不可控，或者浏览器会使用 URL 的最后一部分作为文件名。
  • 跨域限制： 如果下载链接与当前页面不同源，可能存在跨域问题。
  • 无法对文件内容进行前端处理： 在下载前或下载后无法对文件内容进行修改、预览等操作。

二. 通过 Blob 对象下载

工作原理：

Blob（Binary Large Object）对象表示一个不可变的、原始数据的类文件对象。通过 XMLHttpRequest 或 Fetch API 以 responseType: 'blob' 请求二进制数据，获取到 Blob 对象后，可以利用 URL.createObjectURL() 方法创建一个临时的 URL，然后通过 <a> 标签触发下载。

async function downloadWithBlob(url, filename) {
    try {
        const response = await fetch(url);
        if (!response.ok) {
            throw new Error(`HTTP error! status: ${response.status}`);
        }
        const blob = await response.blob(); // 获取 Blob 对象

        const urlObject = window.URL.createObjectURL(blob);
        const link = document.createElement('a');
        link.href = urlObject;
        link.download = filename; // 由前端指定文件名，也可以从响应头中获取
        document.body.appendChild(link);
        link.click();
        document.body.removeChild(link);
        window.URL.revokeObjectURL(urlObject); // 释放 URL 对象

    } catch (error) {
        console.error('Download failed:', error);
    }
}

// 示例
// downloadWithBlob('http://example.com/api/getFileData', 'report.xlsx');

适用场景：

• 需要认证的下载： 当下载文件需要自定义请求头（如 Authorization token）进行身份认证时，fetch 或 XMLHttpRequest 可以很好地支持。
• 前端处理文件内容： 在下载前需要对文件内容进行预览、压缩、解密、格式转换等操作时，Blob 是非常方便的中间数据格式。
• 生成文件： 前端动态生成文件内容（例如 CSV、图片、PDF），然后将其打包成 Blob 进行下载。
• 获取下载进度： fetch 或 XMLHttpRequest 可以监听下载进度事件。
• 后端只返回二进制数据，前端控制文件名： 当后端只返回纯粹的二进制数据，文件类型和文件名需要前端来判断或指定时。

使用差异：

• 优点：
  • 支持认证和自定义请求头： 能够处理复杂的认证场景。
  • 前端可控性高： 可以在下载前对文件内容进行处理，支持动态生成文件。
  • 可获取下载进度： 通过 fetch 或 XMLHttpRequest 可以监听下载进度。
  • 前端可定义文件名和文件类型： 可以灵活指定下载文件的名称和 MIME 类型。
• 缺点：
  • 内存占用： 对于非常大的文件，将整个文件内容加载到内存中可能会占用较多内存。
  • 兼容性： 较老的浏览器可能不支持 Blob 或相关 API。
  • 需要手动释放 URL： URL.createObjectURL() 创建的 URL 需要通过 URL.revokeObjectURL() 手动释放，否则可能导致内存泄漏。

三. 通过 ArrayBuffer 对象下载

工作原理：

ArrayBuffer 对象用于表示通用的、固定长度的原始二进制数据缓冲区。与 Blob 类似，通过 XMLHttpRequest 或 Fetch API 以 responseType: 'arraybuffer' 请求二进制数据，获取到 ArrayBuffer 后，通常会将其转换为 Blob，然后再通过 URL.createObjectURL() 触发下载。

async function downloadWithArrayBuffer(url, filename, mimeType = 'application/octet-stream') {
    try {
        const response = await fetch(url);
        if (!response.ok) {
            throw new Error(`HTTP error! status: ${response.status}`);
        }
        const arrayBuffer = await response.arrayBuffer(); // 获取 ArrayBuffer 对象

        // 将 ArrayBuffer 转换为 Blob
        const blob = new Blob([arrayBuffer], { type: mimeType });

        const urlObject = window.URL.createObjectURL(blob);
        const link = document.createElement('a');
        link.href = urlObject;
        link.download = filename;
        document.body.appendChild(link);
        link.click();
        document.body.removeChild(link);
        window.URL.revokeObjectURL(urlObject);

    } catch (error) {
        console.error('Download failed:', error);
    }
}

// 示例
// downloadWithArrayBuffer('http://example.com/api/getBinaryData', 'image.png', 'image/png');

适用场景：

• 需要对二进制数据进行底层操作： 当需要直接访问和操作文件的原始字节数据时，ArrayBuffer 是理想的选择。例如，加密/解密文件内容、解析文件头信息、进行位操作等。
• 与其他二进制 API 交互： ArrayBuffer 与 TypedArray（如 Uint8Array、Int32Array 等）和 DataView 紧密结合，方便进行二进制数据的读写。
• 需要认证的下载： 与 Blob 类似，fetch 或 XMLHttpRequest 支持认证请求。
• 获取下载进度： 同样可以通过 fetch 或 XMLHttpRequest 监听下载进度。
• 后端返回的文件格式和文件名称是后端定义的： arrayBuffer 同样可以接收这种响应，然后由前端根据响应头或业务逻辑确定文件名和MIME类型。

使用差异：

• 优点：
  • 底层数据访问： 能够直接操作原始二进制数据，适用于更底层的处理需求。
  • 支持认证和自定义请求头： 同 Blob。
  • 可获取下载进度： 同 Blob。
• 缺点：
  • 需要转换为 Blob 才能下载： ArrayBuffer 本身不能直接创建 URL 进行下载，通常需要先转换为 Blob。
  • 内存占用： 同 Blob。
  • 需要手动释放 URL： 同 Blob。

总结对比

特性	直接触发下载	Blob 对象下载	ArrayBuffer 对象下载
认证/请求头	困难（依赖 Cookie/URL）	容易（通过 Fetch/XHR）	容易（通过 Fetch/XHR）
前端处理	无法处理	方便（预览、压缩、生成等）	方便（底层二进制操作，需转 Blob 下载）
下载进度	无法获取	可获取	可获取
文件名控制	依赖后端 Content-Disposition 或 URL	前端可定义，或从响应头获取	前端可定义，或从响应头获取
内存占用	浏览器管理，前端感知较少	较高（整个文件加载到内存）	较高（整个文件加载到内存）
实现复杂度	低	中等	中等偏高（通常需转 Blob）
适用场景	简单文件、公共文件	需认证、前端处理、动态生成文件、前端控制文件名	需认证、底层二进制操作、前端控制文件名
跨域支持	浏览器处理（可能受 CORS 影响）	完全支持（通过 CORS）	完全支持（通过 CORS）

在最近一次开发中就遇到了重复请求的问题，本文展现了从一个页面加载时触发4次重复API请求，到2次，并最终实现1次请求的解决过程，以免下次再掉进这个坑里。