使用JavaScript及file-saver下载application/zip压缩包损坏无法打开

核心前提：Swagger接口测试下载正常，说明服务端返回逻辑无问题，故障100%出在前端HTTP请求接收、文件处理环节。

最高概率根因（90%以上同类问题都是这个） #

你发起接口请求时没有显式指定响应类型为二进制流，HTTP客户端默认会把返回的zip二进制数据按UTF-8字符串解析，转码过程会直接篡改原始字节，哪怕你后续手动创建Blob声明类型是application/zip，传入的源数据已经是损坏的，最终下载的文件自然无法解压。

排查&修复步骤 #

• 先改接口请求配置
  如果你用axios作为请求库，必须在请求配置中增加responseType: 'blob'字段，注意这个配置是加在请求发送阶段，不是saveAs调用阶段：

  // 接口请求示例
  axios.get('/your/zip/download/path', {
    responseType: 'blob', // 核心必填配置，漏写必出文件损坏
    // 其余原有配置（请求参数、headers等）保持不变
  }).then(response => {
    // 原有保存逻辑可以简化，因为此时response.data已经是Blob实例，不需要手动再包一层
    const disposition = response.headers['content-disposition']
    const filename = disposition.match(/filename="(.+)"/)[1]
    FileSaver.saveAs(response.data, filename)
  })
  

  如果你用原生fetch实现请求，必须通过blob()方法转换响应，不能直接取文本内容：

  fetch('/your/zip/download/path')
    .then(res => res.blob()) // 禁止用res.text()接收二进制数据
    .then(blob => {
      FileSaver.saveAs(blob, 'target.zip')
    })
  

• 快速校验数据是否正常
  分别下载Swagger返回的正常zip、前端代码触发下载的损坏zip，对比两个文件的大小：如果大小存在差异，说明前端接收环节仍然存在转码篡改字节的问题，优先检查请求拦截器里有没有对响应数据做统一的JSON转换、字符串处理逻辑。
• 兼容校验Header读取问题
  HTTP响应头的字段名是不区分大小写的，部分浏览器会自动把Content-Disposition转为全小写格式，你原有代码中读取header时混用了小写content-type和大写Content-Disposition，可能在部分环境下拿不到文件名，触发文件名非法的问题，但这个问题不会导致zip内容本身损坏。
• 无依赖快速验证逻辑
  加完responseType配置后，可以先用原生a标签触发下载做验证，排除file-saver本身的异常：

  const url = URL.createObjectURL(response.data)
  const link = document.createElement('a')
  link.href = url
  link.download = filename
  document.body.appendChild(link)
  link.click()
  document.body.removeChild(link)
  URL.revokeObjectURL(url)
  

  用这段代码如果能下载到可正常解压的zip，说明数据接收逻辑正确，换回file-saver调用即可。

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