前端轮询接口越打越多怎么办：从重复定时器到清理机制一步步排查

前端轮询本来是一个很普通的功能：页面每隔几秒请求一次状态接口，把最新结果展示出来。但有时上线后会发现一个奇怪现象：页面打开越久，接口越打越密；从列表页切到详情页再回来，Network 里同一个接口像排队一样越来越多。

这篇文章不直接给结论，我们按一次排查路径来走：先看现象，再验证是不是重复创建了定时器，接着定位页面离开时没有清理，最后用单例轮询、请求锁、页面隐藏暂停和卸载清理把请求节奏拉回稳定。

摘要

前端轮询接口越打越多，常见原因不是接口本身慢，而是页面反复进入时创建了多个 setInterval，组件卸载或页面隐藏时又没有停止。排查时可以给 timer 和请求编号，观察 Network 是否出现多条并行节奏；修复时让同一页面只保留一个 timer，并在请求未结束、页面隐藏、组件卸载时做好控制。

适合人群

• 正在做订单状态、报表进度、任务队列、消息提醒等轮询功能的前端开发者。
• 遇到同一个接口请求数量持续增加、页面越用越卡、后端日志请求暴涨的读者。
• 想把轮询逻辑整理成可复用清理流程的团队成员。

问题现场：轮询接口越打越多

我们先看一个典型现场。页面有一个任务进度卡片，正常设计是每 3 秒请求一次 /api/report/status。第一次打开页面时看起来没问题，Network 里请求间隔也比较稳定。

问题出现在几次页面切换后。比如从报表页切到详情页，再回到报表页，Network 里同一个接口开始同时出现两条、三条甚至更多请求。再过一会儿，接口耗时也开始升高，页面按钮响应变慢，后端日志里同一个用户的请求数量明显变多。

这张图里最关键的线索是：左边不是单次请求慢，而是多个 setInterval 同时在发同一个接口。也就是说，我们要先查“轮询启动了几次”，而不是一上来就优化接口。

初步判断：是不是重复启动了定时器

很多轮询问题都从类似代码开始。页面进入时调用 startPolling，函数里创建一个定时器，每隔 3 秒请求一次接口。

let timerId = null;

function startPolling() {
  timerId = setInterval(async () => {
    const res = await fetch("/api/report/status");
    const data = await res.json();
    renderStatus(data);
  }, 3000);
}

这段代码本身能工作，但它有一个隐患：每调用一次 startPolling，都会产生一个新的 timer。旧 timer 是否还活着、页面离开时是否清理、请求未返回时是否继续发起下一次请求，这些都没有被约束。

所以我们的第一个猜测是：页面生命周期里多次调用了启动函数，却没有把旧 timer 停掉。

动手验证：给 timer 和请求加编号

猜测不能只靠感觉。接着做一个很小的验证：给每一个 timer 和每一次请求都加编号，观察控制台里是否出现多个 timer 同时发请求。

let timerSeq = 0;
let requestSeq = 0;

function startPolling() {
  const currentTimer = ++timerSeq;
  console.log("timer start", currentTimer);

  return setInterval(async () => {
    const currentRequest = ++requestSeq;
    console.log("poll request", currentTimer, currentRequest);
    await fetch("/api/report/status");
  }, 3000);
}

如果页面只应该有一个轮询，那么控制台里理想状态应该一直只有同一个 timer 编号在发请求。可在问题现场，我们经常会看到这样的节奏：

timer start 1
poll request 1 1
poll request 1 2
timer start 2
poll request 1 3
poll request 2 4
timer start 3
poll request 1 5
poll request 2 6
poll request 3 7

现在证据就比较明确了：不是一个轮询变快了，而是多个轮询叠在一起。接下来要找这些 timer 是在哪里重复创建的。

定位原因：进入页面创建新 timer，离开页面没有清理

轮询通常挂在页面初始化、组件挂载、弹窗打开、筛选条件变化这几个入口。如果这些入口每次触发都创建 timer，而退出时没有对应停止，就会越积越多。

可以从三个地方查：

• 路由进入时是否每次都调用 startPolling。
• 组件销毁时是否调用 clearInterval。
• 筛选条件变化后是否先停止旧轮询，再启动新轮询。

还有一个容易忽略的点：页面切到后台标签页后，用户看不到结果，但轮询可能仍在继续。多个页面标签同时打开时，请求量会进一步放大。到这里，原因基本可以归纳为四句话：重复启动、缺少清理、请求重叠、隐藏页面仍在跑。

修复方案：单例轮询、请求锁、隐藏暂停、卸载清理

现在开始修。目标很明确：同一页面只允许存在一个 timer；上一次请求没结束时不再叠加下一次；页面隐藏时暂停；组件卸载时清理。

1. 只保留一个 timer

先把启动函数改成幂等的。也就是说，多次调用 startPolling，结果仍然只有一个 timer 在工作。

let pollingTimer = null;
let pollingBusy = false;

async function pollOnce() {
  if (pollingBusy) return;
  pollingBusy = true;

  try {
    const res = await fetch("/api/report/status");
    const data = await res.json();
    renderStatus(data);
  } finally {
    pollingBusy = false;
  }
}

function startPolling() {
  if (pollingTimer) return;
  pollOnce();
  pollingTimer = setInterval(pollOnce, 3000);
}

function stopPolling() {
  if (!pollingTimer) return;
  clearInterval(pollingTimer);
  pollingTimer = null;
}

这里有两个关键点。第一，startPolling 看到已有 timer 时直接返回，避免重复创建。第二，pollingBusy 用来阻止请求重叠；如果接口偶尔超过 3 秒才返回，下一次轮询不会继续压上去。

2. 页面隐藏时暂停，恢复可见时再启动

如果业务不需要后台持续刷新，可以结合页面可见性控制轮询。用户切到其他标签页时暂停，回来后再启动。

document.addEventListener("visibilitychange", () => {
  if (document.hidden) {
    stopPolling();
  } else {
    startPolling();
  }
});

这样做能减少无意义请求，特别适合后台管理页面、报表页、任务进度页。对于必须实时在线的场景，则要和业务确认是否允许暂停。

3. 组件卸载时清理

在 React 场景里，轮询通常放在 useEffect 里。返回的清理函数必须停止 timer。

useEffect(() => {
  startPolling();
  return () => {
    stopPolling();
  };
}, []);

如果轮询依赖筛选条件，要注意条件变化时也会触发清理函数。这样旧条件对应的 timer 会先停止，新条件再启动新的轮询。

验证结果：Network 恢复为固定节奏

修完以后不要只看页面“好像不卡了”。我们要回到最开始的证据链，复查三件事。

• 控制台里是否始终只有一个 timer 编号。
• Network 里同一个接口是否按固定间隔出现，没有并行堆积。
• 页面切换、弹窗打开关闭、后台标签页恢复后，请求数量是否仍然稳定。

如果之前 10 分钟能堆出几十条并行请求，修复后应该恢复成每 3 秒一条左右。接口慢的时候，也不会因为请求锁失效而继续叠加。

常见坑位

1. 只清理最后一个 timer

如果重复创建了多个 timer，而变量里只保存最后一个 timer id，那么调用一次 clearInterval 只能停掉最后创建的那个。更好的做法是从源头保证只创建一个。

2. 接口慢时仍按固定间隔继续请求

轮询间隔是 3 秒，不代表接口一定 3 秒内返回。没有请求锁时，慢接口会造成请求重叠，最终表现成请求堆积。

3. 页面隐藏后还在持续刷新

后台标签页里的轮询很容易被忽略。用户打开多个标签页时，每个页面都在请求，后端看到的压力会成倍增加。

4. 切换筛选条件时没有停止旧轮询

报表页经常会根据项目、日期、状态筛选条件重新拉取数据。条件变化后要先停止旧轮询，再用新条件启动，否则旧参数和新参数会同时请求。

总结

前端轮询接口越打越多，排查时不要只盯着接口耗时。更稳的路径是：先看 Network 是否出现并行堆积，再给 timer 和请求加编号，确认是否重复创建，最后检查页面离开、条件变化、标签页隐藏时有没有清理动作。

落地时记住四个控制点：启动函数幂等、请求未完成不叠加、页面隐藏可暂停、组件卸载必清理。只要这四点守住，轮询就能从“越跑越多”恢复成可控的固定节奏。