海量倒计时的性能优化（全局定时器复用）

场景题： “现在的电商大促会场或者外卖订单列表页中，一屏里同时展示了多达 100 个甚至上千个带有秒杀倒计时的商品卡片（例如：剩余 01:25:34，并且每一秒都在跳动）。如果你为每一个组件实例内部都偷偷开一个 setInterval 来做倒计时，页面很快就会严重卡顿、发烫，甚至各个卡片的跳动完全不同步。作为前端，你该如何优雅地优化这种海量定时器的场景？”

这道题考察的是前端对事件循环（Event Loop）性能缺陷的理解，以及使用单例模式 + 观察者模式进行大型项目状态集中管理的能力。

灾难现场：N 个`setInterval` 的雪崩效应

在初级写法的 React/Vue 组件中，如果我们在 useEffect / mounted 里这样写：

// 【极其危险的写法】每个商品卡片内部独立开倒计时
useEffect(() => {
  const timer = setInterval(() => {
    setTimeLeft(endTime - Date.now());
  }, 1000);
  
  return () => clearInterval(timer);
}, []);

如果页面上有 1000 个这样的卡片，意味着浏览器的宏任务队列里每一秒钟会被疯狂塞入 1000 个回调任务！主线程为了在短短的 1000ms 内消化完这 1000 次虚拟 DOM Diff 和渲染，会不堪重负直接堵死。而且因为 setInterval 本身的机制并不绝对精准（受宏任务队列阻塞影响），1000 个倒计时的误差会不断累积，最终你会看到满屏的数字在以不同步的乱拍疯狂“乱跳”，用户体验极其糟糕。

核心架构：单例全局定时器（时钟引擎）

既然大家都是在以“每 1 秒”的频率发生状态改变，我们为什么不造一个统一的**“中控大本钟（Global Clock）”**呢？

整个应用无论有多少个组件需要倒计时，永远只允许存在唯一的一个 setInterval（或 requestAnimationFrame）对象。

通过发布-订阅机制（Pub/Sub）：每个需要倒计时的商品卡片向全局时钟注册自己的需求；全局时钟滴答作响时，一并下发通知更新即可。

纯 JS 逻辑层的实现模型

// time-manager.js
class GlobalTimer {
  constructor() {
    this.intervalId = null;
    this.subscribers = new Set();
  }

  // 组件来注册自己，把更新函数交给我
  subscribe(callback) {
    this.subscribers.add(callback);
    
    // 如果这是全场第一个注册的人，唤醒大本钟
    if (this.subscribers.size === 1) {
      this.start();
    }
    
    return () => this.unsubscribe(callback);
  }

  // 组件销毁时取消订阅
  unsubscribe(callback) {
    this.subscribers.delete(callback);
    // 如果全场已经没有卡片需要倒计时了，直接关闭引擎，极其节省 CPU！
    if (this.subscribers.size === 0) {
      this.stop();
    }
  }

  start() {
    // 永远只会有一个驱动核心
    this.intervalId = setInterval(() => {
      const now = Date.now();
      // 一次循环，批量通知所有正在场上的卡片
      this.subscribers.forEach(cb => cb(now));
    }, 1000);
  }

  stop() {
    if (this.intervalId) {
      clearInterval(this.intervalId);
      this.intervalId = null;
    }
  }
}

export const globalTimer = new GlobalTimer();

业务组件如何优雅接入？

// 商品卡片组件.tsx
import { useEffect, useState } from 'react';
import { globalTimer } from './time-manager';

export const GoodsCard = ({ endTime }) => {
  const [timeLeft, setTimeLeft] = useState(endTime - Date.now());

  useEffect(() => {
    // 将这一个卡片的更新微操作注入全场唯一引擎中
    const unSub = globalTimer.subscribe((currentTime) => {
      const remain = endTime - currentTime;
      if (remain <= 0) {
        setTimeLeft(0);
        unSub(); // 到期主动下车，不再浪费资源被通知
      } else {
        setTimeLeft(remain);
      }
    });

    // 严谨的保命：组件切走销毁时注销下车
    return unSub;
  }, [endTime]);

  return <div>剩余秒数：{Math.max(0, Math.floor(timeLeft / 1000))}</div>;
};

面试官追问与大招（高分防御方案）

Q：如果不用 setInterval，还有没有更精准的方式？

A：精准之神 requestAnimationFrame 配合时间戳补齐。 因为 setInterval 若是被其他的超长 JS 阻塞（比如渲染复杂图表），它会大幅度延迟，时间严重漂移。我们可以用浏览器的重绘之神 requestAnimationFrame(rAF) 来充当引擎。因为 rAF 每秒触发约 60 次，我们在订阅通知时必须通过比对 currentTime - lastTime >= 1000 来做一次节流（Throttle）拦截。这样不仅规避了宏任务丢帧，而且它在浏览器 Tab 切到后台隐身时会自动暂停运转，大幅度节约了笔电用户的电池寿命！

Q：如果不用发布订阅，在 React / Vue 中有不有更为极简的打法？

A：将时间收拢提升为最顶级的 Global Context（或 Vuex / Redux state）。 在根结点仅发起一个定时器，不断改变如 useContext(TimeContext) 里储存的 globalNow。所有的下层的一千个倒计时卡片直接去吃这个 Context 里面的值计算自身时差就能触发视图的重新算数。不过这需要极端强大的组件优化（如 React 的 React.memo）来镇压住因超大全局 Provider 一秒跳一次从而引发一千个子组件在 React 树上疯狂执行全盘 Re-render 的反向翻车性能问题。

总结

对付“海量并发但同质化操作”的业务，大前端的底层套路永远是：提取公因式，降维打击。不管是一个亿的倒计时，还是上万个小球各自的计算动画。永远记住不要让成千上万个马达在前端的这单线程引擎上内耗乱撞；建立**一个全局统调的大管家（单例模式）**进行收口并批处理发牌，方为前端架构师的首选破局之举。

ON THIS PAGE

#海量倒计时的性能优化（全局定时器复用）

#灾难现场：N 个setInterval 的雪崩效应

#核心架构：单例全局定时器（时钟引擎）

#纯 JS 逻辑层的实现模型

#业务组件如何优雅接入？

#面试官追问与大招（高分防御方案）