如何修复或规避轮询调用fetch API时出现的内存泄漏问题？

问题归因 #

这个问题同时存在代码写法缺陷和Chromium内核（Chrome、Edge均基于该内核）的已知设计限制：

1. 代码层面的核心问题：你在全局state对象中持久持有了完整Response实例的引用，且没有消费/关闭响应流。Response对象底层绑定了浏览器原生层的网络响应缓冲区，只要你持续持有引用且未关闭流，这部分内存就不会被GC回收，且缓冲区属于原生内存，不会在JS堆快照中显示，只能通过系统任务管理器观测。
2. 浏览器层面的限制：即便你正确处理了响应对象，高频拉取大体积资源时，Chromium的网络栈对原生缓冲区的回收存在延迟，会等到内存达到阈值才会批量清理，持续轮询时资源分配速度超过回收速度，就会出现内存持续攀升的情况。

解决方案 #

1. 修正Response处理逻辑（必改） #

不要持有任何不必要的Response引用，根据你的业务需求处理完响应后立刻释放底层资源：

• 如果你不需要读取响应内容，直接关闭响应流即可：

fetch('你的请求地址')
.then(response => {
  // 直接关闭流，释放底层缓冲区
  response.body?.cancel()
  // 不要把response赋值给任何全局变量
  // 后续业务逻辑
})

• 如果你需要读取响应内容，仅保留你需要的业务数据，不要存储整个Response：

fetch('你的请求地址')
.then(async response => {
  // 根据业务需要读取对应格式的内容，比如json、text、blob等
  const result = await response.json()
  // 仅存储业务需要的result，不要保存response
  state.responseData = result
  // 主动断开引用，帮助GC回收
  response = null
  // 后续业务逻辑
})

2. 优化轮询调度逻辑 #

避免请求堆积，主动管理请求生命周期：

• 每次发起新请求前，用AbortController终止上一次未完成的请求，避免无用请求占用内存：

let requestController = null
function poll() {
  // 终止上一次未完成的请求
  if (requestController) requestController.abort()
  requestController = new AbortController()
  
  fetch('你的请求地址', {
    signal: requestController.signal
  })
  .then(/* 业务逻辑 */)
  .catch(err => {
    // 忽略主动终止的请求报错
    if (err.name !== 'AbortError') {
      console.error('请求失败', err)
    }
  })
}

• 如果仅需要判断资源更新状态，不需要拉取完整内容，改用HEAD请求，仅获取响应头，大幅减少数据传输量和内存占用。

3. 极端场景的规避方案 #

如果是内部使用的可控客户端，可以给Chrome/Edge添加启动参数--js-flags="--expose-gc"，在代码中每完成若干次轮询后主动调用gc()强制触发垃圾回收，该方案不适用于面向普通用户的生产环境。

按照上述方案修改后的代码，持续轮询时内存会维持在稳定区间，不会出现无限制上涨的问题。

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