JSZip调用generateAsync生成Blob时切换同窗口浏览器标签导致执行停滞的问题咨询

我用以下代码生成包含DICOM文件的新压缩包：

let newZipFile = await compressAllDicoms(newDicoms); 
async function compressAllDicoms(dicoms) { 
  let zip = new JSZip(); 
  let i = 0; 
  eventBus.$emit('updateProgressText', "compressingDicoms"); 
  dicoms.forEach((file) => { 
    if (file) { 
      zip.file(file.filename, file.content, {binary: true}); 
    } 
  }); 
  return zip.generateAsync({type: "blob", streamFiles: true}, function updateCallback(metadata) { 
    eventBus.$emit('updatePb', Math.ceil(metadata.percent)); 
  }) 
}

遇到的问题是：执行zip.generateAsync()这部分逻辑时，如果用户切换到浏览器同窗口内的其他标签页，压缩操作会直接冻结；只有切回原标签页后，进度才会继续。这个问题只在FireFox和Chrome出现，而且只发生在同窗口标签页切换的场景——如果只是让浏览器窗口失焦（比如打开其他程序）但不切换标签，压缩能正常进行；打开新浏览器窗口但不切换原窗口的标签，也能正常执行。

请问这个问题的成因可能是什么？

可能的成因分析 #

这个问题其实和Chrome、Firefox对后台标签页的资源管理策略直接相关，具体可以从这几个角度理解：

• 后台标签的JS执行节流：Chrome和Firefox都有针对后台标签的性能优化机制——当某个标签页不是当前窗口的活动标签时，浏览器会大幅限制该标签内的JavaScript执行优先级，甚至暂停一些CPU密集型的异步任务。zip.generateAsync()本质上是运行在主线程的CPU密集型操作，虽然它通过回调分步更新进度，但整个压缩过程还是需要持续占用主线程时间片。当标签被切换到后台，浏览器会把大部分CPU资源分配给当前活动标签，导致压缩任务几乎得不到执行机会，直到你切回原标签。

• 浏览器对“失焦窗口”和“后台标签”的区别对待：这是关键的一点——浏览器会区分「整个窗口失焦」和「同窗口内标签切换」两种状态。如果只是浏览器窗口被其他程序挡住，但当前标签还是该窗口的活动标签，浏览器认为这个标签仍然是用户可能在关注的，不会触发严格的节流；但一旦你在同窗口内切换到其他标签，原标签就被标记为“后台标签”，这时浏览器就会启动严格的资源限制，包括限制主线程的JS执行频率。

• JSZip的分步执行依赖主线程时机：JSZip的generateAsync()是分批次处理压缩任务的，每完成一部分就调用回调更新进度。但这些批次的执行完全依赖主线程的调度。在后台标签下，浏览器会延迟这些批次的执行调度，导致压缩进度看起来完全冻结，直到标签回到前台，调度恢复正常，压缩才继续。

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