ReactJS中如何检测XHR请求间隔的网络空闲以触发应用级定时器

目标逻辑：不绑定用户UI交互、组件导航行为，以最后一次服务端请求完成为起点，达到指定时长无新请求时触发预设动作，即使用户全程在界面做本地操作也不打断空闲计时。

核心实现逻辑 #

• 完全不依赖click/scroll/touch/keydown这类传统用户交互事件作为空闲判定依据
• 空闲状态的判定唯一参考维度：所有出方向的服务端请求的生命周期
• 定时器重置的触发规则仅和请求状态绑定：所有在途请求全部结束时，重新开始计时空闲时长
• 完全不会被用户的本地UI操作打断：比如用户点按钮切路由、滚动页面、修改本地状态这类不产生服务端请求的行为，都不会重置定时器，精准匹配“网络空闲而非交互空闲”的判定需求
• 天然和组件路由、导航逻辑解耦，无需在每个页面单独埋点

具体实现步骤 #

1. 全局请求拦截 #

不逐个在业务代码里埋点，统一在全局拦截原生XMLHttpRequest和fetch请求，避免漏记造成定时器计时不准。
关键注意点：计时起点是请求结束时刻，而非请求发起时刻——如果请求本身耗时较长，从发起时计时会导致空闲判定偏移。

2. 封装可复用的监控类 #

class NetworkIdleMonitor {
  /**
   * @param {number} idleThresholdMs 空闲触发阈值（毫秒）
   * @param {Function} onIdleTrigger 空闲触发后的回调
   */
  constructor(idleThresholdMs, onIdleTrigger) {
    this.idleThresholdMs = idleThresholdMs;
    this.onIdleTrigger = onIdleTrigger;
    this.timer = null;
    this.inflightRequestCount = 0; // 统计在途请求数，避免请求未完成就启动计时
    window.__networkMonitorInstance = this;
    this.bindGlobalRequestInterceptor();
  }

  // 定时器重置逻辑
  _restartTimer() {
    // 还有在途请求时，暂不启动计时
    if (this.inflightRequestCount > 0) return;
    // 清除上一轮的旧定时器
    clearTimeout(this.timer);
    this.timer = setTimeout(() => {
      this.onIdleTrigger();
    }, this.idleThresholdMs);
  }

  // 绑定全局请求拦截逻辑
  bindGlobalRequestInterceptor() {
    // 拦截XHR请求
    const originalXhrOpen = XMLHttpRequest.prototype.open;
    const originalXhrSend = XMLHttpRequest.prototype.send;
    XMLHttpRequest.prototype.open = function(...args) {
      this._isAppRequest = true;
      return originalXhrOpen.apply(this, args);
    }
    XMLHttpRequest.prototype.send = function(...args) {
      if (!this._isAppRequest) return originalXhrSend.apply(this, args);
      window.__networkMonitorInstance.inflightRequestCount += 1;
      // 监听请求终态（成功/失败/中断都算结束）
      this.addEventListener('loadend', () => {
        window.__networkMonitorInstance.inflightRequestCount -= 1;
        // 所有在途请求结束时，重启空闲计时器
        if (window.__networkMonitorInstance.inflightRequestCount === 0) {
          window.__networkMonitorInstance._restartTimer();
        }
      })
      return originalXhrSend.apply(this, args);
    }

    // 拦截fetch请求
    const originalFetch = window.fetch;
    window.fetch = async function(...args) {
      window.__networkMonitorInstance.inflightRequestCount += 1;
      try {
        return await originalFetch.apply(this, args);
      } finally {
        window.__networkMonitorInstance.inflightRequestCount -= 1;
        if (window.__networkMonitorInstance.inflightRequestCount === 0) {
          window.__networkMonitorInstance._restartTimer();
        }
      }
    }
  }

  // 资源销毁
  destroy() {
    clearTimeout(this.timer);
    window.__networkMonitorInstance = null;
    // 生产环境可根据需求恢复原生XHR/fetch的原始实现，避免热更新重复绑定
  }
}

3. React应用集成方式 #

因为是全局层级逻辑，仅在应用根组件入口初始化一次即可，无需在路由、页面组件里重复配置：

import { useEffect } from 'react';
export default function RootApp() {
  useEffect(() => {
    // 初始化：设置10分钟空闲时长，触发对应逻辑
    const idleMonitor = new NetworkIdleMonitor(10 * 60 * 1000, () => {
      // 在此处写预设逻辑，比如超时登出、弹窗提示
      console.log('达到网络空闲阈值，触发预设动作');
    });
    // 应用卸载时销毁实例，避免内存泄漏
    return () => idleMonitor.destroy();
  }, []);
  return <div>应用页面内容</div>
}

性能影响说明 #

• 整体性能开销几乎可以忽略：全局拦截逻辑仅在初始化时执行一次，每个请求的拦截动作仅做计数和绑定终态事件，无DOM读取、复杂计算操作，即便页面高频发请求也不会造成主线程卡顿
• 需要规避的性能坑：
  • 拦截逻辑中不要嵌入异步操作、复杂判断，避免拉长请求链路的响应时间
  • 必须做实例销毁和拦截绑定的去重，否则开发环境热更新、路由切换时会重复绑定拦截，导致内存泄漏、定时器多次重置
  • 如果项目已经在用Axios等封装好的请求库，直接在库的请求/响应拦截器里埋点，比全局重写原生XHR/fetch的性能开销更低

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