依赖日志模块访问express-http-context获取reqId返回undefined

该问题是典型的npm依赖多实例冲突导致的上下文隔离问题：

• express-http-context基于Node.js的async_hooks（CLS）实现请求上下文存储，所有读写操作都绑定在**当前模块实例自身持有的命名空间（namespace）**上，不同模块实例的命名空间完全独立、数据不互通。
• 你的公共日志包@coverforce-platform/cf-logger-module如果在自身dependencies中声明了express-http-context依赖，包管理工具安装依赖时会为日志包单独存放一份独立的express-http-context代码副本，和主服务node_modules根目录下的express-http-context是两个完全无关的模块实例。
• 主服务中注册的httpcontext.middleware、express-ruid写入reqId的操作，都是在主服务持有的express-http-context实例的命名空间上执行；而日志包内读取上下文时，访问的是自身副本持有的空命名空间，因此永远返回undefined。主服务业务代码直接引用根目录的模块实例，因此可以正常读取到reqId，和你观察到的现象完全匹配。

方案1（推荐，长期规范） #

修改公共日志包的package.json，将express-http-context从dependencies移到peerDependencies中，强制所有使用该日志包的服务统一提供依赖版本，避免多副本问题：

{
  "peerDependencies": {
    "express-http-context": "^1.2.4"
  }
}

修改后重新发布日志包版本，主服务升级到新版本后，删除node_modules目录和对应lock文件（package-lock.json/yarn.lock/pnpm-lock.yaml）重新安装依赖即可。

修复后可以通过以下方式验证：分别在主服务业务代码、日志包代码中打印require.resolve('express-http-context')，如果两个输出的文件路径完全一致，说明已复用同一模块实例。

方案2（临时快速修复，无需发版日志包） #

如果暂时无法修改公共日志包的代码，可以通过依赖注入的方式绕过多实例问题：

1. 改造日志包，暴露初始化方法，支持外部传入express-http-context实例，包内所有上下文读取操作都使用外部传入的实例，不再自行require依赖：

// 日志包内部代码
let injectedHttpContext = null;
function initLogger(config) {
  injectedHttpContext = config.httpContext;
  // 其余winston实例初始化、transport配置逻辑
}

// 日志格式化逻辑中读取reqId
const reqId = injectedHttpContext.get('reqId');

2. 主服务初始化日志时，将自身持有的express-http-context实例传入：

const httpContext = require('express-http-context');
const { initLogger } = require('@coverforce-platform/cf-logger-module');
initLogger({ httpContext });

不要在winston实例初始化、transport构造的同步阶段读取上下文值，这类代码只在服务启动时执行一次，此时没有请求进入上下文，取值必然为空。你当前在printf格式化、元数据process方法中读取的写法是符合要求的，无需调整。

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