如何获取Node.js进程内所有执行帧的堆栈跟踪

你已知的console.trace()、new Error().stack仅能获取当前同步执行路径的调用栈，无法覆盖被异步调度切出、处于I/O等待、定时器挂起状态的逻辑执行流。要实现运行中进程全量堆栈采集，可按场景选择以下方案：

基于V8 Inspector的无侵入采集方案 #

这是最接近GDB原生效果的方案，不需要修改业务代码，依赖V8内置的调试能力实现全异步栈追踪：

• 启动Node.js进程时添加--inspect=127.0.0.1:自定义端口参数开启本地Inspector服务，生产环境务必绑定127.0.0.1避免外部端口暴露
• 连接进程Inspector服务后，先调用Runtime.enable接口启用运行时域，再调用Runtime.setAsyncCallStackDepth设置异步栈保留深度（日常排查设为32即可覆盖绝大多数业务调用场景）
• 需要采集堆栈时，通过Profiler域做极短时间的采样，即可拿到所有活跃执行上下文的完整栈帧：包括当前正在运行的同步调用栈、所有挂起等待回调的异步执行流栈，输出结构和GDB的全线程回溯完全对应，每个独立执行流单独列出栈信息。

可以直接用Node.js内置的inspector模块实现采集逻辑，无需安装第三方依赖：

const inspector = require('inspector');
const session = new inspector.Session();
session.connect();

// 初始化Inspector能力，开启异步栈追踪
session.post('Runtime.enable');
session.post('Runtime.setAsyncCallStackDepth', { maxDepth: 32 });
session.post('Profiler.enable');

/**
 * 采集进程内所有活跃执行流的堆栈
 * @returns {Promise<Array>} 所有执行流的栈帧列表
 */
function dumpAllStacks() {
  return new Promise((resolve) => {
    session.post('Profiler.start', () => {
      // 10ms短采样覆盖所有活跃上下文，对业务性能影响可忽略
      setTimeout(() => {
        session.post('Profiler.stop', (err, { profile }) => {
          if (err) return resolve([]);
          // 解析采样结果，还原每个执行流的完整调用链
          const allStacks = profile.nodes.map(node => {
            const frameList = [];
            let currentNode = node;
            while (currentNode) {
              frameList.push({
                functionName: currentNode.callFrame.functionName,
                scriptUrl: currentNode.callFrame.url,
                lineNumber: currentNode.callFrame.lineNumber,
                columnNumber: currentNode.callFrame.columnNumber
              });
              currentNode = profile.nodes.find(item => item.id === currentNode.parent);
            }
            return frameList.reverse();
          });
          resolve(allStacks);
        });
      }, 10);
    });
  });
}

• 如果进程使用了worker_threads启动独立工作线程，每个Worker是独立V8实例，需要在Worker内部单独创建Inspector会话采集堆栈，再汇总到主线程输出，才能覆盖所有执行上下文。

基于async_hooks的生产环境无调试端口方案 #

如果部署环境不允许开启Inspector调试端口，可以用Node.js内置的async_hooks模块自主维护所有活跃异步上下文的堆栈：

• 初始化async_hooks实例，在init钩子（异步资源创建时触发）中记录当前调用栈，绑定到对应异步资源的唯一ID上
• 在destroy钩子（异步资源销毁时触发）中及时删除对应ID的栈记录，避免内存泄漏
• 需要采集全量堆栈时，遍历所有存活异步资源ID绑定的栈信息，加上当前同步执行栈，即可得到全量逻辑执行流的堆栈。

这个方案的注意事项：

• 会产生一定性能开销，建议生产环境合理设置栈采集深度，不要保留过多冗余栈帧
• 默认不会追踪C++层面的原生异步资源（比如底层TCP连接的内核态回调），启动时添加--async-stack-traces参数可以补全这类栈信息
• 不要在钩子函数中写复杂逻辑，避免阻塞事件循环。

能力边界说明 #

• Node.js虽然是单线程事件循环模型，但每个挂起等待回调的异步操作都对应独立的逻辑执行上下文，V8本身会保留这些上下文的栈信息，只是默认不对业务代码暴露
• Error.captureStackTrace和new Error().stack能力边界一致，都只能获取当前同步执行路径的栈，无法拿到挂起状态的异步栈
• 主流Node.js APM工具的全链路栈采集能力，本质都是基于上述两种方案做封装优化。

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