Node.js AsyncLocalStorage官方示例执行顺序与文档不符问题排查

1. 实际执行顺序与文档不同的原因 #

官方文档的示例预期输出基于旧版本Node.js（大致v18之前）的HTTP请求处理行为，而你使用的v20/v22版本中，HTTP客户端默认启用了keepAlive连接复用机制，且请求调度逻辑发生了变化。当连续调用两次http.get时，第二个请求会复用第一个请求的连接，导致服务器需要等待第一个请求处理完成（包括res.end()关闭连接）后，才会接收并处理第二个请求。这就造成了第一个请求的start→finish完整执行后，才会触发第二个请求的start。

2. 与Node.js事件循环机制的关系 #

完全相关，核心在于事件循环的阶段调度：

• HTTP服务器的请求回调触发于poll阶段，当客户端请求到达时，回调会被加入poll队列等待执行。
• setImmediate的回调会被加入check阶段，该阶段在poll阶段之后执行。
  在新版本中，第二个请求的连接复用导致其请求直到第一个请求的连接关闭后才进入poll队列，因此事件循环会先处理第一个请求的poll阶段逻辑（输出0: start），接着进入check阶段执行setImmediate回调（输出0: finish），之后回到poll阶段才处理第二个请求的逻辑，最终形成你看到的顺序。
  而旧版本中，两个请求会建立独立连接，同时进入poll队列，事件循环会先执行两个请求的poll阶段逻辑（输出0: start、1: start），再进入check阶段执行两个setImmediate回调，形成文档中的预期顺序。

3. 修改代码实现「start start finish finish」的模式 #

要让两个请求的服务器回调在第一个setImmediate执行前都被触发，关键是让服务器同时接收到两个请求，避免连接复用导致的排队。可以通过以下方式修改：

方法1：禁用HTTP客户端的keepAlive #

让两个请求建立独立连接，确保服务器同时处理：

const http = require('node:http');
const { AsyncLocalStorage } = require('node:async_hooks');

const asyncLocalStorage = new AsyncLocalStorage();

function logWithId(msg) {
  const id = asyncLocalStorage.getStore();
  console.log(`${id !== undefined ? id : '-'}:`, msg);
}

let idSeq = 0;
const server = http.createServer((req, res) => {
  asyncLocalStorage.run(idSeq++, () => {
    logWithId('start');
    setImmediate(() => {
      logWithId('finish');
      res.end();
    });
  });
}).listen(8081, () => {
  // 禁用keepAlive，发起两个独立连接的请求
  const req1 = http.get('http://localhost:8081', { keepAlive: false });
  const req2 = http.get('http://localhost:8081', { keepAlive: false });
  req1.end();
  req2.end();
});

方法2：使用Promise.all同时发起请求 #

通过Promise.all确保两个请求几乎同时发送：

// 服务器部分不变，修改请求发起逻辑
server.listen(8081, async () => {
  await Promise.all([
    new Promise(resolve => http.get('http://localhost:8081', resolve)),
    new Promise(resolve => http.get('http://localhost:8081', resolve))
  ]);
});

4. 对AsyncLocalStorage实际应用的影响 #

这种差异不会影响AsyncLocalStorage的核心功能。AsyncLocalStorage的设计目标是在异步调用链中保留上下文，保证每个请求的独立上下文不会被混淆——无论执行顺序如何，0的上下文只会出现在第一个请求的异步链中，1的上下文只会出现在第二个请求的异步链中。
实际应用中，请求的执行顺序本身就是不确定的，业务代码不应该依赖请求的执行顺序来实现逻辑，因此这种行为差异不会对生产环境的使用造成影响。

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