Node.js如何重建Promise拒绝场景下的完整调用栈追踪

问题描述 #

我遇到了和公开技术讨论场景相似但不完全一致的问题：实现了一个返回Promise的函数，内部执行HTTP调用，请求出错时会在响应返回后触发reject。因为HTTP请求存在网络耗时，请求发送阶段Node.js会处理其他指令，等请求返回抛出错误时，输出的栈追踪起点固定为processTicksAndRejections——这是所有异步操作的共同特征，直接导致无法追溯该函数的原始调用位置。

初始常规实现 #

const fetch = require('node-fetch');

function myFunction() {
  return new Promise(async (resolve, reject) => {
    fetch('https://www.google.com').then(() => {
      return reject(new Error('Whoops!'));
    });
  });
}

myFunction().catch(console.log);

运行后输出的错误栈如下：

Error: Whoops!
    at /home/dami/projects/testing/stack.js:8:21
    at processTicksAndRejections (internal/process/task_queues.js:95:5)

手动拼接栈的尝试 #

曾尝试手动拼接栈追踪的方案：函数初始化时就捕获当前调用栈，异步抛出错误时把初始化阶段捕获的栈拼接到错误栈上，实现代码如下：

function myFunction() {
  const stack = (new Error()).stack;

  return new Promise(async (resolve, reject) => {
    fetch('https://www.google.com').then(() => {
      const error = new Error('Test');
      error.stack += stack;
      reject(error);
    });
  });
}

myFunction().catch(console.log);

运行后输出的栈如下：

Error: Test
    at /home/dami/projects/testing/stack.js:8:21
    at processTicksAndRejections (internal/process/task_queues.js:95:5)Error
    at myFunction (/home/dami/projects/testing/stack.js:4:18)
    at a (/home/dami/projects/testing/stack.js:16:3)
    at Object.<anonymous> (/home/dami/projects/testing/stack.js:19:1)
    at Module._compile (internal/modules/cjs/loader.js:1085:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
    at Module.load (internal/modules/cjs/loader.js:950:32)
    at Function.Module._load (internal/modules/cjs/loader.js:790:12)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:76:12)
    at internal/main/run_main_module.js:17:47

这个方案的缺陷是输出栈存在两段独立来源：一段是run_main_module对应的Node进程启动链路，一段是processTicksAndRejections对应的异步调度链路，格式杂乱不规范。也尝试过换用async/await语法、把reject逻辑放到函数顶层，但受异步操作的本质限制，错误始终会被processTicksAndRejections捕获，无法天然拿到完整调用栈。

公认最佳解决方案 #

Node.js 12+ 原生支持异步栈追踪，默认配置下异步调用链丢失本质是两个原因：一是代码里存在不必要的Promise包装、冗余的async声明打断了栈追踪链路；二是没有开启长栈追踪（long stack trace）支持。

1. 先修正代码中的反模式 #

初始代码里存在两个会破坏栈追踪的写法：

• 不需要在new Promise的executor里加async关键字，executor本身不需要返回Promise，加async反而会引入额外的微任务层打断栈链路
• 不需要手动套一层Promise包装fetch的返回值，fetch本身已经返回Promise，多余的嵌套会增加栈追踪的断层

修正后的基础写法：

const fetch = require('node-fetch');

async function myFunction() {
  await fetch('https://www.google.com');
  throw new Error('Whoops!');
}

myFunction().catch(console.error);

Node.js 14+ 运行这段代码，已经可以拿到比之前完整很多的调用栈，不会直接截断在processTicksAndRejections。

2. 开启原生长栈追踪支持 #

如果需要跨多个异步事件循环周期保留完整调用栈，直接开启Node.js内置的--async-stack-traces启动参数即可，不需要手动拼接栈：

node --async-stack-traces your-script.js

开启后所有异步操作的栈会自动拼接同步调用链路，不会出现手动拼接时两段栈格式断裂的问题，是Node.js官方维护的标准实现。

3. 旧版本Node.js兼容方案 #

如果运行环境低于Node.js 12，可以用成熟的开源长栈追踪库做支持，不需要侵入业务代码，只需要在入口文件最顶部引入即可：

require('longjohn');

引入后会自动替换默认的异步调度逻辑，自动收集全链路调用栈，输出格式和原生错误栈完全一致，没有手动拼接的格式问题。

注意：手动拼接栈的方案只适合临时调试，生产环境不要使用。一方面会在函数同步执行阶段额外生成Error对象带来性能损耗，另一方面拼接后的栈格式不符合V8默认的错误栈规范，会导致日志采集、错误监控系统无法正确解析栈信息。

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