1 篇博文 含有标签「EventEmitter」

请求日志中间件在 res.on('finish') 回调里读 AsyncLocalStorage 的 traceId，getStore() 返回 undefined，每条响应日志的 traceId 都是空的。

在为客户开发 电商数据采集工具 时遇到此问题——服务端用 ALS 把每条请求的 traceId 贯穿整条处理链路，但响应日志死活关联不上，排查发现是「晚回调」丢了上下文。

TL;DR​

res.on('finish') 这类 EventEmitter 回调，触发时已经脱离了注册它时的 async context，als.getStore() 自然拿不到请求的 store。最稳的解法是在同步段把值取到闭包变量，回调里直接用闭包值；需要完整 store 时则在回调内 als.run(store, fn) 重建上下文。

问题现象​

一个看起来毫无问题的请求日志中间件：

// middleware/requestLog.js
import { als } from '../utils/als.js';

app.use((req, res, next) => {
  res.on('finish', () => {
    const store = als.getStore();
    logger.info({
      traceId: store?.traceId,  // 响应日志里这里永远是 undefined
      statusCode: res.statusCode,
    }, 'request');
  });
  next();
});

中间件顺序没问题，traceId 在请求处理链路里（路由、业务函数）都读得到，唯独 res.on('finish') 里读不到。更迷惑的是：把 als.getStore() 挪到 next() 之前的同步段，它就有值。

根因​

AsyncLocalStorage 靠 Node 的 async_hooks 把 store 绑定到当前激活的 async context 上，顺着异步调用链往下传。als.run(store, fn) 的语义是：在 fn 执行期间（及其派生的异步任务里），getStore() 都能拿到这个 store。

问题出在 EventEmitter。res.on('finish', cb) 做的事是把 cb 注册成监听器，等响应发送完毕后由 EventEmitter 的事件循环触发。触发 cb 的那个 async context，是 EventEmitter 派发事件时所在的上下文——不是注册它时的请求上下文。而且响应发送通常发生在请求处理链路之后，请求对应的 als.run 作用域可能已经退出。

所以 cb 里 als.getStore() 拿到的是「当前激活上下文」的 store，而那个上下文根本不属于这次请求，结果就是 undefined（或更糟，串到别的上下文）。

凡是「注册时一个上下文、触发时另一个上下文」的回调都有这个坑：res.on('finish')、once、某些 setTimeout/setInterval、chrome.alarms 监听器等等。

解决方案​

按场景给两个模式，按需选。

模式 A（推荐）：同步段闭包捕获​

如果你的回调只需要 store 里的某几个值（最常见就是 traceId），最简单也最可靠——在同步段（store 一定存活的时刻）把值取出来存进闭包，回调里直接用闭包变量，彻底不依赖 ALS：

app.use((req, res, next) => {
  // 同步段：此时一定在 als.run 作用域内，getStore() 必有值
  const traceId = als.getStore()?.traceId;
  const start = Date.now();

  res.on('finish', () => {
    // 回调里用闭包里的 traceId，不再碰 ALS
    logger.info({
      traceId,                         // 稳定拿到
      statusCode: res.statusCode,
      durationMs: Date.now() - start,
    }, 'request');
  });

  next();
});

这一步把「异步上下文是否还活着」这个不确定性，换成了一个确定的闭包引用。回调何时触发都不影响——值已经在闭包里了。

模式 B：als.run 重建上下文​

当回调里要调用一坨内部都依赖 getStore() 的代码（比如 logger 的 mixin、Sentry 的 scope 注入），逐个改成闭包不现实，就在回调入口重建上下文：

res.on('finish', () => {
  const traceId = capturedTraceId;       // 同步段捕获的值
  if (traceId) {
    // 在回调内重新建立 ALS 上下文，后续 record() 内部 getStore() 能正常拿到
    als.run({ traceId }, () => record(res, start));
  } else {
    record(res, start);
  }
});

als.run(store, fn) 会为 fn 建立一个新的、独立的 async context 并把 store 绑上去，fn 内部及它派生的异步调用都能读到。这比 als.enterWith 更安全——后者改写的是「当前共享上下文」，在并发场景下会串值，那是另一个坑，见 AsyncLocalStorage 并发读到错误的值？enterWith 改用 run 隔离上下文。

常见问题​

为什么 res.on('finish') 回调里读不到 AsyncLocalStorage 的值？​

res.on('finish', cb) 把 cb 注册为 EventEmitter 监听器，响应发送完毕后才触发。触发时的 async context 是事件派发所在的上下文，不是注册它的请求上下文，请求的 als.run 作用域可能已退出，因此 getStore() 返回 undefined。

怎么让 EventEmitter 回调重新拿到 AsyncLocalStorage 上下文？​

最简单的是在同步段把需要的值取到闭包变量，回调里直接用闭包值；如果回调内部有大量依赖 getStore() 的代码，则在回调入口用 als.run(store, fn) 重建上下文。前者优先，后者用于改造既有逻辑。