Vue3项目Blob方式下载PDF在移动端内置浏览器失效如何解决

架构老林

2026-8-27

问题根因

第三方App内嵌WebView（如Facebook、社交类App内置的Web容器）普遍存在两类限制，导致现有下载逻辑失效：

未完整实现HTML5下载规范：不支持通过JS动态创建<a>标签、绑定Blob地址、模拟点击触发下载的逻辑，部分容器会直接拦截非用户手动触发的下载行为，且完全忽略<a>标签的download属性
安全策略限制：部分裁剪版WebView内核会拦截URL.createObjectURL生成的blob://协议地址，直接禁止这类本地地址的加载/跳转
代码在系统自带浏览器可正常运行，是因为系统浏览器完整实现了相关标准，和内嵌WebView的内核能力存在差异。

修复方案

做两层兼容处理，覆盖绝大多数内嵌WebView场景：

补全原有逻辑的资源回收：创建的Blob URL用完必须释放，动态插入的a标签触发点击后要移除，避免内存泄漏
增加环境判断，对不支持Blob下载的内嵌WebView走兜底逻辑：直接跳转地址打开PDF，引导用户通过WebView自带的长按保存/菜单保存功能存储文件；如果后端支持配置Content-Disposition: attachment响应头，优先直接跳转接口地址触发下载，兼容性最高。

修复后的完整代码：

async function downloadPdfLink(args: IPaymentDownloadPDFArguments): Promise<void> {
  isPDFLoading.value = true;
  let blobUrl: string | null = null;

  try {
    const response = await get(
      `/users/${args.userId}/payments/${args.paymentId}/download-pdf`,
      { responseType: 'arraybuffer' }
    );

    const blob = new Blob([response.data], { type: 'application/pdf' });
    blobUrl = window.URL.createObjectURL(blob);
    const fileName = `${convertToKebabCase(args.name)}${moment(new Date()).format("_YYYY_DD_MM")}.pdf`;

    // 检测环境是否支持a标签download属性
    const supportAnchorDownload = 'download' in document.createElement('a');
    // 粗略匹配第三方内嵌WebView环境
    const isInThirdWebView = /WebView/i.test(navigator.userAgent) && !/Safari|Chrome/i.test(navigator.userAgent.match(/(Safari|Chrome)\/[\d.]+/)?.[0] || '');

    if (supportAnchorDownload && !isInThirdWebView) {
      // 标准浏览器环境走原有下载逻辑
      const link = document.createElement('a');
      link.href = blobUrl;
      link.download = fileName;
      document.body.appendChild(link);
      link.click();
      document.body.removeChild(link);
    } else {
      // 内嵌WebView兜底：直接打开PDF，支持用户长按保存
      // 最优方案是替换为后端返回的带Content-Disposition头的直链地址，兼容性最好
      window.location.href = blobUrl;
    }
  } catch (reason) {
    throw new Error(reason as string);
  } finally {
    // 释放Blob资源
    if (blobUrl) window.URL.revokeObjectURL(blobUrl);
    isPDFLoading.value = false;
  }
}

额外注意事项

不要在内嵌WebView场景下强依赖download属性指定文件名，绝大多数内嵌WebView会忽略这个属性，文件名需要通过后端的Content-Disposition响应头配置才能生效
如果跳转Blob地址仍然失败，直接放弃前端转Blob的逻辑，改为直接跳转到后端的下载接口地址，让后端返回附件响应头触发下载，这种方案的兼容性覆盖99%以上的移动WebView环境
不要在无用户交互的回调里触发下载逻辑，部分WebView会拦截异步回调里触发的跳转/下载行为，必须保证下载逻辑是在用户点击事件的调用链里执行。

内容的提问来源于stack exchange，提问作者HOHOOH