遇到Node.js进程内存只涨不降，我一般先不急着看业务代码，而是先确认是不是定时器在“偷偷存活”。定时器泄漏问题比较隐蔽，因为异步函数执行完，定时器还可能留在事件循环里。下面是我处理这类问题的顺序，沿着这个思路排查即可。

先确认泄漏是不是定时器造成的

在Node.js中，异步函数里使用setInterval或setTimeout后，如果函数执行完毕但定时器未被清除，该定时器会持续持有其回调函数中引用的变量，导致这些变量无法被垃圾回收。判断是否存在此类泄漏，可以观察进程内存占用是否随请求或函数调用次数增加而单调上升，且波动回收后仍不回落到初始水平。另一个特征是，长时间运行后，堆快照中能看到大量处于pending状态的Timeout或Interval对象，且它们的引用链指向已结束调用的闭包环境。

在实际观察时，我建议先用“进程重启后内存是否回落”这个简单标准做初筛。如果重启后内存持久下降，说明存在累积性引用。再配合日志里请求数和内存的曲线，能看得更清楚。注意，正常的GC抖动也会让内存上下波动，关键是看整体趋势是否持续走高。

把泄漏的定时器从堆里找出来

要定位未清理的定时器，可以在Node.js中开启--expose-gc运行脚本，并在关键节点手动触发global.gc()，随后使用heapdump或v8.writeHeapSnapshot生成快照。在快照中搜索Timeout或Interval构造函数，观察其实例数量是否持续增长。同时，可以使用process._getActiveHandles()和process._getActiveRequests()列出当前活跃的句柄，若其中包含定时器而对应业务上下文已经结束，则说明存在泄漏点。线上环境可借助async_hooks为每个异步资源绑定调用栈，从而追踪定时器的创建位置。

我通常会在代码里加一个临时接口，触发一次全局GC后生成快照。比如：

const v8 = require('v8');
const fs = require('fs');
function snapshot() {
  if (global.gc) global.gc();
  const name = 'heap-' + Date.now() + '.heapsnapshot';
  fs.writeFileSync(name, v8.writeHeapSnapshot());
}

生成快照后，在Chrome DevTools的Memory面板里打开，用关键词“Timeout”或“Interval”过滤，看实例的保留大小。如果大量实例的引用链都指向同一个已经结束的函数，那就说明定时器没被正确清理。同时，也可以在Node.js REPL里执行代码process._getActiveHandles()，直接看当前活跃的句柄类型和数量。不过这个方法属于非公开API，升级Node.js版本后可能变动，只能用来临时排查。

修复时用这个模式避免漏网

修复时可参考以下模式：在异步函数内部创建定时器前，先声明一个句柄变量和一个清理函数；在函数的所有出口（包括正常返回、抛出异常、Promise resolve/reject）调用清理函数。例如，使用setInterval实现轮询时，在拿到最终结果后优先调用clearInterval，并将回调函数中的对外部数据的引用置为null。若定时器用于Promise超时，可在Promise内部设置setTimeout，并在finally中清除，确保即使Promise进入settled状态也不会残留超时定时器。这样能从根本上切断定时器对闭包变量的引用链。

我自己的习惯是把定时器句柄放在局部变量中，然后在最后用try-finally包裹。比如实现一个带超时的Promise：

function withTimeout(promise, ms) {
  let timer = null;
  return Promise.race([
    promise,
    new Promise((resolve, reject) => {
      timer = setTimeout(() => reject(new Error('timeout')), ms);
    })
  ]).finally(() => clearTimeout(timer));
}

这里的关键是finally一定会在Promise settled后执行，所以超时定时器不会残留。对于递归setTimeout，也建议在每次递归前检查退出条件，并在出口处清除。clearInterval同理。

几个容易漏掉的小地方

除了上面的模式，实际开发中还有很多漏网点。比如在Promise的then或catch中临时创建了定时器，以为函数执行完就没事了，但resolve或reject之后的代码仍然运行，定时器并没有被清除。又比如用定时器做超时控制时，正常响应后没有取消超时定时器，这个定时器会一直等到触发才结束。还有一种情况是频繁创建短生命周期定时器，但句柄被重复赋值，旧的定时器失去引用后就再也无法clear了。

如果你用数组保存多个定时器句柄，删除时下标处理不正确，数组会持续膨胀。这不止是内存问题，还会让回调逻辑定位变得困难。我在项目里通常不维护动态数组，而是用一个Map来存句柄，配合业务ID做增删，避免数组里残留空位。

有些未清理的定时器并不需要太焦虑

不是所有未清理的定时器都会立刻造成严重的内存泄漏。如果定时器回调内部不引用外部变量，并且定时器本身没有因为其他引用链被全局持有，那么随着进程重复调用，内存占用可能一直保持在较低水平。但风险在于，定时器一旦被某个全局缓存或长寿对象引用，泄漏就会随缓存增长不断放大。

另外，unref()可以让定时器不阻止进程退出，但它并不会让定时器变得“不影响内存”。它只解决进程无法自然退出的问题，对象引用导致的驻留依然存在。所以清理时机最好放在异步函数真正完成之后，而不是依赖进程生命周期来判断。

处理这类问题的顺序，建议先从现象和堆快照确认是定时器泄漏，再利用工具定位创建位置，然后用上面提到的“句柄变量+finally清理”模式修复，同时检查几个常见的漏网点。这样基本能覆盖大部分未清理定时器引起的内存上涨问题。