Node.js API循环并发请求时返回其他请求旧结果问题咨询

这是Node.js服务端非常典型的跨请求上下文污染问题，核心诱因是违反了Node.js单进程并发模型下的变量作用域规则：你把本该属于单次请求的参数、中间处理状态，存到了所有并发请求共享的内存区域里。
Node.js采用单线程事件循环处理请求，所有并发请求共享同一份进程内存。当你把请求传入的用户ID、查询中间结果存在全局对象、模块顶层变量、单例类实例属性这类跨请求共享的位置时，只要出现并发请求：后进入的请求会直接覆盖前序请求还在处理中的共享变量值，等前序请求走到数据库查询、结果组装步骤时，读到的已经是被后序请求篡改过的值，自然会返回和请求ID不匹配的错误数据。
串行请求、请求间加延迟时不会触发问题，本质是前一个请求已经走完了全处理流程、共享变量已经完成读写释放，后一个请求才进来修改变量，不会出现中途覆盖的情况。

常见触发场景 #

• 隐式或显式声明全局变量存请求状态，比如直接写currentUserId = req.params.id漏了声明关键字，或者显式挂载到global对象上，所有请求读写同一份值
• 模块顶层（路由文件、服务文件最外层）声明变量存请求级数据，比如文件开头写let queryUserId = ''，每个请求进来先给这个变量赋值，后续全链路逻辑都读这个变量
• 采用单例模式导出的服务类、工具类中，用类实例属性存储请求级数据，所有请求复用同一个类实例，属性值会被并发请求反复覆盖
• 错误封装数据库查询逻辑：全局提前构造了一个带状态的查询实例，每个请求只修改这个实例的查询条件，并发时条件互相覆盖
• 跨异步链路传递上下文时，自行用共享变量实现上下文存储，没有用官方提供的隔离方案，导致上下文串流

在接口处理全链路的三个关键节点打日志：接收请求参数提取用户ID的位置、数据库查询传入参数的位置、响应结果组装的位置，每次日志同时打印当前请求传入的原始ID、以及代码逻辑中实际使用的ID值。并发压测一次就能看到，前序请求走到查询逻辑时，代码实际取到的ID已经被后序请求覆盖，顺着被污染的变量往上找，就能定位到错误的变量声明位置。

• 严格遵循作用域规则：所有请求级别的数据，必须存在当前请求的独立作用域内。最稳妥的做法是直接把请求相关的参数、中间状态挂载到当前请求的req对象上（比如req.userId = req.params.id），后续所有处理逻辑都从req对象取值，每个请求的req对象完全独立，不会出现跨请求污染。
• 需要跨多层函数、跨异步调用传递请求上下文时，不要自行用共享变量实现存储，直接使用Node.js内置的稳定API AsyncLocalStorage做上下文隔离，它基于async_hooks实现，能保证每个异步链路拿到独立的上下文副本，不会被并发请求篡改，基础用法示例：

const { AsyncLocalStorage } = require('async_hooks');
// 模块顶层创建异步存储实例，全局唯一
const requestContext = new AsyncLocalStorage();

// 在接口最前置的全局中间件中初始化每个请求的独立上下文
app.use((req, res, next) => {
  const context = {
    userId: req.params.id,
    requestId: Math.random().toString(36).slice(2)
  };
  // 后续所有在这个回调里的异步逻辑，都能拿到当前请求的独立context
  requestContext.run(context, next);
});

// 任意业务逻辑中，无需透传req对象即可拿到当前请求的上下文，不会串
function getCurrentUser() {
  const ctx = requestContext.getStore();
  return userDb.findById(ctx.userId);
}

• 排查所有单例导出的服务、工具类：单例对象上只允许存无状态的通用方法、全局配置项，绝对不能存储任何和单次请求绑定的用户数据、临时状态。
• 检查ORM/数据库查询逻辑：每个请求的查询条件、查询实例必须在当前请求的处理函数内独立构造，不要复用全局提前创建的带状态查询对象。
• 全量代码排查变量声明：所有局部变量必须加let/const声明，避免隐式创建全局变量导致的污染。

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