使用axios下载600MB大文件页面崩溃内存不足问题咨询

问题核心原因 #

当前实现一次性将完整600MB文件加载为ArrayBuffer存入JS堆内存，加上解密过程生成的临时对象、解密后明文副本，总内存占用很容易突破浏览器单标签页的内存上限（桌面端Chrome单标签JS堆上限约1.4GB，移动端、32位浏览器上限更低），直接触发页面崩溃。
由于你需要在内存中完成解密后再交付文件，核心优化思路是尽可能降低内存峰值占用，避免全量密文长期驻留内存。

最优方案：流式分片下载+增量解密 #

这是通用的大文件前端处理标准方案，可将内存峰值降低70%以上：

• 放弃等全量文件下载完成再处理的逻辑，对接HTTP响应的可读流，每次读取1~4MB大小的密文分片
• 每读到一个分片就送入支持增量处理的解密器计算，不需要保留全量密文在内存中
• 解密完成的明文分片暂存，所有分片处理完成后拼接为Blob交付用户
• 浏览器端优先使用原生Fetch API实现流式读取，axios在浏览器端对流式响应的兼容性不如原生Fetch稳定

参考实现代码：

// 分片大小可根据实际解密块大小调整，建议1~4MB
const CHUNK_SIZE = 2 * 1024 * 1024
const decryptedChunks = []
let receivedSize = 0

// 发起请求，直接读取响应流
const res = await fetch(url, {
  headers: {
    "Authorization": authHeader().Authorization,
    "Accept": "application/octet-stream"
  }
})
if (!res.ok) throw new Error(`下载失败，状态码：${res.status}`)
const totalSize = Number(res.headers.get('Content-Length'))
const reader = res.body.getReader()

// 初始化增量解密器，需匹配使用的加密算法，优先选AES-GCM/CTR等流模式加密
const decryptor = initStreamDecryptor()

while (true) {
  const { done, value } = await reader.read()
  if (done) break
  // 直接对当前分片做增量解密，不需要留存密文分片
  const plainChunk = decryptor.process(value)
  decryptedChunks.push(plainChunk)
  receivedSize += value.length
  // 此处可自行实现下载进度逻辑：进度 = receivedSize / totalSize
}
// 处理解密收尾逻辑，比如最后一个块的填充移除
const finalPlainChunk = decryptor.finalize()
if (finalPlainChunk) decryptedChunks.push(finalPlainChunk)

// 拼接解密后的明文生成文件，触发用户下载
const fileBlob = new Blob(decryptedChunks)
const tempUrl = URL.createObjectURL(fileBlob)
const downloadLink = document.createElement('a')
downloadLink.href = tempUrl
downloadLink.download = "目标文件名"
downloadLink.click()
// 释放临时URL避免内存泄漏
URL.revokeObjectURL(tempUrl)

注意：该方案要求解密逻辑支持增量输入，如果当前使用的是需要全量密文才能解密的算法（比如固定填充的AES-CBC），需要先调整加密端为流加密模式。

无法使用流式解密的兜底方案 #

如果暂时无法调整加密算法为流模式，可通过以下配置降低内存峰值：

• 关闭axios默认的响应转换逻辑，避免生成多份内存副本，修改请求配置如下：

axios.get(url, {
  headers: { 
    "Authorization": authHeader().Authorization,
    "Accept" : "application/octet-stream"            
  },   
  responseType: 'arraybuffer',
  transformResponse: [] // 关闭默认响应转换，直接返回原始二进制数据
})

• 为站点启用跨域隔离，申请更大的JS内存上限，需要服务端配合返回两个响应头：
  • Cross-Origin-Opener-Policy: same-origin
  • Cross-Origin-Embedder-Policy: require-corp
    开启后可使用SharedArrayBuffer存储大文件数据，内存上限可提升到4GB以上。
• 不要在解密过程中对原始ArrayBuffer做slice、拷贝操作，会额外生成冗余内存副本推高占用峰值
• 解密完成后第一时间将密文ArrayBuffer的引用置为null，主动触发GC回收，不要将大对象绑定到window、组件实例等长生命周期对象上。
• 不要使用responseType: 'blob'，Blob本质还是会在内存中存储全量文件，不会降低内存占用。

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