使用FileReader与Promise时出现JavaScript内存泄漏问题

嗨，我完全理解你遇到的这个困扰——上传342MB的CT扫描文件目录后，内存占用一直居高不下，哪怕是没对数据做任何操作的示例里也能看到内存持续增长，明明上传完成后该释放的内存却没被回收，确实很影响应用的稳定性。结合你的描述，我整理了几个可能的原因和对应的解决办法：

1. 文件对象的引用残留是最常见的原因 #

浏览器处理上传时会把文件内容加载到内存生成Blob/File对象，如果这些对象被意外保留在全局变量、闭包、未清理的事件监听里，垃圾回收器就没法回收它们。比如你可能在代码里写了类似window.currentFiles = selectedFiles这样的全局存储，或者某个上传回调函数一直持有文件引用，都会导致内存占着不放。

• 解决办法：上传完成（无论成功失败）后，主动解除所有对文件对象的引用：

  // 把全局存储的文件列表置空
  window.currentFiles = null;
  // 移除文件相关的事件监听
  fileInput.removeEventListener('change', handleFileSelect);
  // 如果用了框架，在组件卸载时清理文件状态
  // 比如React里的useEffect返回清理函数：
  // return () => { setUploadFiles(null); };
  

2. FormData对象未及时清理 #

如果你用FormData封装上传的文件，部分浏览器不会自动回收FormData里的文件引用，尤其是当FormData对象还被其他变量引用时，会一直持有内存。

• 解决办法：在上传的成功/失败回调里，把FormData对象也设为null，切断它对文件数据的持有：

  function handleUploadSuccess() {
    // 清理FormData引用
    uploadFormData = null;
    // 其他后续逻辑...
  }
  

3. 浏览器的延迟垃圾回收机制 #

有时候不是代码的问题，而是浏览器为了性能，会延迟触发垃圾回收——它会等到内存压力足够大的时候才自动回收闲置的内存。你可以手动触发验证一下：

• 打开Chrome DevTools的「Memory」面板，上传前拍一张内存快照；
• 上传完成后，点击面板里的垃圾桶图标手动触发垃圾回收；
• 再拍一张快照对比，如果内存明显下降，说明只是浏览器还没自动回收，不是内存泄漏。

4. 文件读取流未正确关闭 #

如果你的代码里用到了FileReader或者流式读取API，要是读取完成后没关闭流、没移除事件监听，也会导致内存泄漏。比如FileReader的onload事件如果一直挂着，会持续持有文件数据的引用。

• 解决办法：在读取完成后主动清理：

  const reader = new FileReader();
  reader.onload = function(e) {
    // 处理读取结果...
    // 清理事件监听和reader对象
    reader.onload = null;
    reader.abort();
  };
  reader.readAsArrayBuffer(file);
  

另外，针对你的JSFiddle示例，哪怕没处理数据，也可能是变量作用域的问题——比如文件列表被存在了全局数组里，或者XMLHttpRequest对象没被清理（比如xhr还在全局作用域）。你可以检查示例里的变量，确保上传完成后所有和文件相关的对象都没有被意外保留。

最后推荐一个排查技巧：用Chrome DevTools的Memory面板对比快照，查看Blob/File类型的对象数量，看看上传后是不是有大量对象没被回收，这样能精准定位到哪个部分的引用没清理。

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