使用setInterval轮询等待条件成立是否属于不良实践？

先直接给结论：绝对不推荐用1ms间隔的setInterval来轮询等待条件，主要问题集中在这几点：

• CPU资源被疯狂消耗：浏览器的主线程需要每隔1ms就被唤醒一次执行条件检查——哪怕条件离满足还远得很。这种高频轮询会抢占页面渲染、用户交互等关键任务的资源，轻则导致页面卡顿，重则在低性能设备上直接让浏览器变卡甚至无响应。而且浏览器本身有最小定时器延迟限制（比如Chrome中，嵌套定时器到一定次数后最小间隔会自动变成4ms），你写1ms其实也达不到预期的精确性，纯纯做无用功。
• 潜在的执行队列问题：如果你的doMyAction()是个比较耗时的操作，或者主线程刚好被其他任务阻塞，setInterval的回调会被堆积在任务队列里，一旦条件满足，极端情况下可能出现多次执行的风险（哪怕你加了clearInterval也难保万无一失）。

更好的替代方案 #

根据你的等待场景，选对应的方案才是正确姿势：

1. 等待DOM变化（比如某个元素出现） #

用MutationObserver——这是浏览器专门用来监听DOM变化的API，完全不需要轮询，效率拉满：

// 监听目标元素的出现
const observer = new MutationObserver((mutations) => {
  const targetEl = document.querySelector('#your-target-element');
  if (targetEl) {
    doMyAction();
    observer.disconnect(); // 满足条件就停止监听
  }
});

// 开始监听body下的所有子元素变化
observer.observe(document.body, { childList: true, subtree: true });

2. 等待某个变量/状态变化 #

用Promise封装，结合requestAnimationFrame（适合和UI相关的状态）或者合理间隔的setTimeout：

function waitForCondition(checkFn) {
  return new Promise((resolve) => {
    const poll = () => {
      if (checkFn()) {
        resolve();
      } else {
        // 用requestAnimationFrame对齐浏览器渲染帧，比固定间隔更高效
        requestAnimationFrame(poll);
        // 如果是非UI相关的，也可以用setTimeout(poll, 50)，选个平衡响应和性能的间隔
      }
    };
    poll();
  });
}

// 使用示例
await waitForCondition(() => window.isSomeStateReady);
doMyAction();

3. 实在要轮询？至少调整间隔 #

如果以上方案都不适用，非得用轮询，那把间隔调到至少50ms甚至100ms——这个间隔下用户感知不到延迟，同时CPU压力会小很多。

总之，这种1ms轮询的写法属于“用最笨的方法解决问题”，完全没必要，换个更合适的方案既高效又靠谱。

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