Node.js高负载场景下setTimeout偶发不执行回调问题排查

Node.js 不存在“过期定时器被自动丢弃”的逻辑，你观察到的单线程执行链中断，和CPU卡顿导致的轮询延迟没有关系，核心是代码链路存在覆盖盲区，或者高负载下触发了边缘异常。 #

Node.js的定时器基于libuv实现，完全不是“固定周期轮询、过期太久就跳过”的逻辑，执行流程是：

1. 调用setTimeout时，JS层会立刻将回调、到期时间存入按到期时间排序的最小堆，同时把最近一个定时器的到期时间传给libuv。
2. 每次事件循环进入timer阶段时，libuv会直接取当前系统时间，把堆中所有到期时间小于等于当前时间的定时器全部取出，按注册顺序挨个执行回调——不管过期了几秒还是几分钟，只要定时器没有被主动clear，就一定会进入执行队列，不存在跳过陈旧任务的逻辑。
3. 你观察到“单线程冻结、其余线程正常”的现象，恰恰可以排除全局定时器逻辑故障：如果是底层轮询机制出问题，所有定时器都会一起失效，不会出现部分正常部分冻结的情况。

结合高负载长运行场景的常见case，你遇到的问题90%概率是以下原因之一：

• 异常捕获存在盲区：你当前的try/catch只能捕获同步执行的代码异常，如果业务逻辑里存在未加await的异步调用、Promise实例没有绑定catch回调，抛出的异步异常不会被外层try/catch捕获，只会触发unhandledRejection。Node.js 12/14默认配置下这类异常只会打印一条warning，不会终止进程，但会直接中断当前线程的执行链，后续的setTimeout根本没机会注册。
• 定时器被意外clear：setTimeout返回的定时器ID是递增复用的整数，如果你代码其他位置存在clearTimeout逻辑，没有做好变量作用域隔离（比如把timerId存在全局变量、闭包引用错误），高负载下连续数天创建销毁数百万定时器后，会出现ID撞车，刚好把你递归线程的下一次定时器clear掉，回调自然不会触发，且完全不影响其他定时器运行。
• 日志误导：高负载下console.log是异步跨线程写stdout，存在概率性的日志延迟、丢失，你看到的“停在Going to sleep日志”不一定是真的执行到了setTimeout那行，有可能是日志还没来得及写入就被异常打断了。

直接上可落地的无侵入调试手段，不需要改业务逻辑：

1. 全局打补丁追踪全链路定时器状态，在业务代码最顶部加入以下逻辑：

const activeTimers = new Map();
const originSetTimeout = global.setTimeout;
const originClearTimeout = global.clearTimeout;

// 劫持全局setTimeout
global.setTimeout = function(cb, delay, ...args) {
  const timerId = originSetTimeout(() => {
    activeTimers.delete(timerId);
    cb.apply(this, args);
  }, delay, ...args);
  // 记录定时器注册时间、延迟、注册堆栈
  activeTimers.set(timerId, {
    registerAt: Date.now(),
    delay,
    registerStack: new Error().stack
  });
  return timerId;
};

// 劫持全局clearTimeout
global.clearTimeout = function(timerId) {
  activeTimers.delete(timerId);
  return originClearTimeout(timerId);
};

// 独立检查逻辑，每10秒扫描一次异常定时器
setInterval(() => {
  const now = Date.now();
  for (const [id, info] of activeTimers) {
    const expireDuration = now - info.registerAt - info.delay;
    // 过期超过1分钟还没触发也没被清除，打印异常
    if (expireDuration > 60 * 1000) {
      console.error(`[TIMER ABNORMAL] 定时器${id}已过期${Math.floor(expireDuration/1000)}秒未触发，注册堆栈：\n${info.registerStack}`);
    }
  }
}, 10 * 1000).unref();

这段代码会追踪所有定时器的注册、清除、触发行为，一旦出现定时器注册后超过1分钟没执行，会直接打印该定时器的注册位置堆栈，直接定位是哪里注册的定时器出问题、有没有被意外clear。
2. 启动Node.js时加上--unhandled-rejections=strict参数，让所有未捕获的Promise rejection直接抛出崩溃，不要让进程带着未捕获的异步异常继续运行，排除异步异常漏捕获的问题。
3. 替换console.log为同步写文件的日志库（比如pino的同步模式），避免高负载下日志丢失、延迟误导排查方向。 #

你的场景只要求回调不丢、对精度要求不高，不要依赖单条递归setTimeout链保活，做两层兜底即可：

1. 加独立看门狗机制，和业务递归逻辑完全解耦：

const THREAD_SLEEP_TIME = 30 * 1000;
const threadLastRunAt = [0, 0, 0];

function someFnc(threadNum) {
  threadLastRunAt[threadNum] = Date.now();
  try {
    console.log(`[${threadNum}] Execution...`);
    // 业务逻辑
    console.log(`[${threadNum}] Going to sleep 30s...`);
    setTimeout(() => someFnc(threadNum), THREAD_SLEEP_TIME);
  } catch(e) {
    console.error(e);
    setTimeout(() => someFnc(threadNum), 1000);
  }
}

// 看门狗逻辑，不依赖业务的setTimeout链
setInterval(() => {
  const now = Date.now();
  threadLastRunAt.forEach((lastRun, threadNum) => {
    if (now - lastRun > THREAD_SLEEP_TIME * 2) {
      console.error(`[WATCHDOG] 线程${threadNum}执行超时，主动兜底触发`);
      setImmediate(() => someFnc(threadNum));
    }
  });
}, 15 * 1000).unref();

// 启动线程
someFnc(0);
someFnc(1);
someFnc(2);

看门狗每15秒检查一次每个线程的最后执行时间，如果超过正常间隔2倍还没跑，直接主动触发一次执行，从根本上避免单链路断了之后线程永久冻结。
2. 如果每天要跑数百万次setTimeout，建议替换原生setTimeout为时间轮实现的定时器，大幅减少定时器创建销毁的开销，同时避免高负载下原生定时器最小堆操作的边缘bug，CPU占用能降30%以上。
3. 不要假设任何异步API是100%可靠的，长运行高负载场景下，GC长停顿、第三方C++扩展bug、第三方库误改全局API都可能导致异步链路中断，核心保活逻辑一定要做跨链路兜底。 #

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