会**同时运行多个版本**，不是最后统一选择一个 `qs`。

关键规则是：

> 哪个模块执行了 `require('qs')`，Node.js 就以**这个模块所在目录**为起点查找 `node_modules/qs`；找到最近的一份就用哪一份。Node.js 官方明确说明，裸包名的解析会从调用模块所在目录开始逐层向父目录查找 `node_modules`。([Node.js][1])

所以结合你的 Spartacus 依赖树，实际情况大致如下。

## 1. Express 5.2.1 运行时使用 `qs@6.14.2`

你的输出开头是：

```text
qs@6.14.2
node_modules/qs
  qs@"^6.14.0" from express@5.2.1
  node_modules/express
```



目录结构可以抽象成：

```text
Spartacus/
│
└─ node_modules/
   ├─ qs/
   │  └─ package.json       # 6.14.2
   │
   └─ express/
      └─ ...
```

假设 Express 内部执行：

```javascript
const qs = require('qs');
```

Node.js 会从：

```text
Spartacus/node_modules/express/
```

开始找：

```text
Spartacus/node_modules/express/node_modules/qs
```

没有。

于是向上一层：

```text
Spartacus/node_modules/qs
```

找到了。

因此：

```text
express@5.2.1
        ↓ require('qs')
qs@6.14.2
```

所以**这条 Express 5.x 运行链实际执行的是 `qs@6.14.2`**。

---

## 2. Karma 那条链运行的却是 `qs@6.15.1`

你的依赖树中另外有：

```text
qs@6.15.1
node_modules/body-parser/node_modules/qs
  qs@"~6.15.1" from body-parser@1.20.5
  node_modules/body-parser
    body-parser@"^1.19.0" from karma@6.4.4
```



目录实际上类似：

```text
node_modules/
│
├─ qs/
│  └─ 6.14.2
│
├─ karma/
│
└─ body-parser/
   │
   └─ node_modules/
      └─ qs/
         └─ 6.15.1
```

当：

```text
body-parser@1.20.5
```

内部执行：

```javascript
require('qs')
```

Node.js 先检查：

```text
node_modules/body-parser/node_modules/qs
```

这里就已经找到了：

```text
qs@6.15.1
```

于是直接停止。

它根本不会继续找到：

```text
node_modules/qs@6.14.2
```

因此 Karma 这条执行链是：

```text
Karma
  ↓
body-parser@1.20.5
  ↓
require('qs')
  ↓
qs@6.15.1
```

也就是说，**运行 Karma 测试时完全可能实际执行 `qs@6.15.1`，同时另外一些 Angular / Express 工具运行的是 `6.14.2`。**

---

# 3. 老 `request` 代码运行的是 `qs@6.5.5`

你还有：

```text
qs@6.5.5 dev
node_modules/request/node_modules/qs
  qs@"~6.5.2" from request@2.88.2
```



对应：

```text
node_modules/
├─ qs/
│  └─ 6.14.2
│
└─ request/
   └─ node_modules/
      └─ qs/
         └─ 6.5.5
```

那么：

```javascript
// request 包内部
require('qs')
```

首先遇到：

```text
request/node_modules/qs
```

所以运行的是：

```text
qs@6.5.5
```

而不是 `6.14.2`。

这也是为什么安全扫描中即使看到：

```text
根目录 qs 已经比较新
```

也绝不能推断：

```text
整个项目所有 qs 都比较新
```

因为：

```text
request → qs@6.5.5
```

可以独立存在。

---

# 4. Verdaccio 又运行 `qs@6.15.3`

你的输出：

```text
qs@6.15.3 dev
node_modules/verdaccio/node_modules/qs

qs@"~6.15.1" from express@4.22.2
node_modules/verdaccio/node_modules/express

express@"4.22.2" from verdaccio@6.8.0
```



可以画成：

```text
verdaccio@6.8.0
      │
      ▼
express@4.22.2
      │
      │ require('qs')
      ▼
qs@6.15.3
```

所以启动 Verdaccio 时，Verdaccio 自己那套 Express 运行的很可能就是：

```text
node_modules/verdaccio/node_modules/qs
```

即：

```text
6.15.3
```

而不是根目录：

```text
6.14.2
```

---

# 5. Webpack Dev Server 运行的是 `qs@6.15.2`

你还有：

```text
qs@6.15.2 dev
node_modules/webpack-dev-server/node_modules/qs

qs@"~6.15.1" from express@4.22.2

express@"^4.22.1" from webpack-dev-server@5.2.5
```



所以：

```text
webpack-dev-server
        ↓
express@4.22.2
        ↓
qs@6.15.2
```

如果运行：

```bash
ng serve
```

或者某个经过 Angular / Nx 调起的 Webpack Dev Server，那么其中的 HTTP Server 路径就可能实际执行：

```text
qs@6.15.2
```

---

# 6. Rspack / Nx 也有自己的 `6.15.2`

你的结果还有：

```text
node_modules/@rspack/dev-server/node_modules/qs
    qs@6.15.2
```



以及：

```text
node_modules/@nx/module-federation/node_modules/qs
    qs@6.15.2
```



以及：

```text
node_modules/@nx/rspack/node_modules/qs
    qs@6.15.2
```



所以整个工程运行时实际上可以出现：

```text
同一个 Node.js process
│
├─ module A
│  └─ qs@6.14.2
│
├─ module B
│  └─ qs@6.15.1
│
├─ module C
│  └─ qs@6.15.2
│
└─ module D
   └─ qs@6.15.3
```

这在 Node.js 中完全正常。

Node.js 的模块缓存甚至也是按照**最终解析出来的文件路径**工作的。官方文档明确提醒：由于不同调用位置可能解析到不同文件，同一个 `require('foo')` 不保证永远得到同一个模块实例。([Node.js][1])

---

# 7. 所以不存在“npm 最后选了一个版本”的过程

这是最重要的认识。

很多人会把 npm 想象成：

```text
发现：

qs@6.5.5
qs@6.14.2
qs@6.15.1
qs@6.15.2
qs@6.15.3

↓

npm 最后挑一个，比如 6.15.3

↓

所有代码全部用 6.15.3
```

**实际不是这样的。**

真正结构是：

```text
                     ┌─ Express 5 ─────────→ qs@6.14.2
                     │
                     ├─ Karma → BodyParser → qs@6.15.1
                     │
Spartacus workspace ─┼─ WebpackDevServer ──→ qs@6.15.2
                     │
                     ├─ Verdaccio ─────────→ qs@6.15.3
                     │
                     └─ request ───────────→ qs@6.5.5
```

npm 安装阶段只是构造：

```text
node_modules dependency topology
```

真正运行时由 Node.js module resolver 决定：

```text
这一次 require('qs')
到底解析到哪个物理目录？
```

npm 官方也明确说，`npm explain` 展示的是**导致某个 package 被安装的 dependency chain**，而不是一个所谓的最终运行版本选择结果。([npm Docs][2])

---

# 8. 那么如果是你自己在 Spartacus 根目录写 `require('qs')` 呢？

假设你在根目录创建：

```javascript
// test.js
const qs = require('qs');

console.log(require.resolve('qs'));
console.log(require('qs/package.json').version);
```

然后：

```bash
node test.js
```

按照你现在的 tree，基本会得到类似：

```text
C:\...\spartacus\node_modules\qs\lib\index.js
6.14.2
```

因为调用者在 root project：

```text
Spartacus/test.js
```

Node.js 查找：

```text
Spartacus/node_modules/qs
```

第一站就找到：

```text
6.14.2
```

所以：

```text
root code
   ↓
require('qs')
   ↓
qs@6.14.2
```

---

# 9. 可以直接在你电脑上验证

Node.js 官方专门提供：

```javascript
require.resolve()
```

用于回答：

> 如果现在 `require()` 这个 module，到底会加载哪个文件？

([Node.js][1])

你在 Spartacus 根目录执行：

```bash
node -p "require.resolve('qs')"
```

应该会看到类似：

```text
D:\...\spartacus\node_modules\qs\lib\index.js
```

再执行：

```bash
node -p "require('qs/package.json').version"
```

就应该是：

```text
6.14.2
```

但注意：

**这只能证明“从 root project 发起 `require('qs')` 时用的是 6.14.2”。**

它不能证明：

```text
Karma
Webpack Dev Server
Verdaccio
Request
```

内部也使用 `6.14.2`。

---

# 10. 可以精确模拟 `body-parser` 是怎么解析的

Node.js 的 `createRequire()` 很适合验证这个问题。

例如执行：

```bash
node -e "const {createRequire}=require('module'); const r=createRequire(require.resolve('body-parser/package.json')); console.log(r.resolve('qs')); console.log(r('qs/package.json').version)"
```

按你的 tree，应该解析到类似：

```text
...\node_modules\body-parser\node_modules\qs\lib\index.js
6.15.1
```

于是你就亲眼证明：

```text
root require('qs')
        ↓
6.14.2

body-parser require('qs')
        ↓
6.15.1
```

二者在同一个项目里并不矛盾。

---

# 11. 但还有一个更关键的问题：Spartacus 浏览器运行时到底用哪个？

如果你所谓的：

> `最后运行时`

是指：

> **用户打开 SAP Commerce Cloud Spartacus / Composable Storefront 网站以后，Chrome 浏览器里实际跑的是哪个 `qs`？**

那么答案需要更加谨慎：

**仅凭 `npm explain qs`，目前不能证明浏览器最终运行了上述任何一个 `qs`。**

因为：

```text
npm dependency tree
```

和：

```text
Angular browser production bundle
```

不是一回事。

例如：

```text
Karma
Webpack Dev Server
Verdaccio
Angular CLI
Lighthouse CI
npm-cli-login
```

明显属于：

```text
开发
测试
构建
本地 server
CI
package registry tooling
```

它们在构建机器上的 Node.js 环境会执行 JavaScript，但并不意味着：

```text
qs
```

最终被 Webpack / esbuild 打进：

```text
main.js
vendor.js
chunk-*.js
```

然后发送给消费者浏览器。

因此要分成两个完全不同的 runtime：

```text
                     Spartacus repository
                            │
            ┌───────────────┴────────────────┐
            │                                │
      Node.js tooling runtime          Browser runtime
            │                                │
    Angular CLI                              │
    Karma                                    │
    Nx                                       │
    Webpack Dev Server                       │
    Verdaccio                                │
    Lighthouse                              │
            │                                │
     多个 qs 都可能运行               qs 可能根本不存在
```

这一步对 CVE 分析尤其重要。

---

# 12. 所以如果你问的是安全漏洞，正确问题不是“最终哪个版本运行”

应该拆成：

```text
问题 A：
哪个 qs 安装在 dependency tree 中？

问题 B：
哪个 qs 会在某个具体 Node.js process 中被加载？

问题 C：
这个 Node.js process 是否暴露给攻击者？

问题 D：
qs 的 vulnerable code path 是否真的能够被 attacker-controlled input 触发？

问题 E：
qs 有没有进入生产 browser bundle？

问题 F：
即使 qs 在开发 tooling 中，它是不是只在 CI / build machine 运行？
```

这比单纯看到：

```text
qs@6.14.2
```

就判断：

```text
生产系统运行 qs@6.14.2
```

严谨得多。

---

## 用你的项目做一个最终归纳

依据当前 `npm explain qs`：

```text
Express 5.2.1
    ↓
qs@6.14.2

Karma
    ↓
body-parser@1.20.5
    ↓
qs@6.15.1

request@2.88.2
    ↓
qs@6.5.5

Verdaccio
    ↓
Express 4.22.2
    ↓
qs@6.15.3

Webpack Dev Server
    ↓
Express 4.22.2
    ↓
qs@6.15.2

Rspack / Nx tooling
    ↓
Express
    ↓
qs@6.15.2
```

所以你的问题最准确的答案是：

> **没有所谓 `最后实际只运行一个 qs 版本`。Node.js 按调用模块的位置解析 dependency，因此同一个 Spartacus workspace 中不同工具链可以同时执行不同版本的 `qs`。根层 Express 5.x 路径使用 `6.14.2`，Karma / Body Parser 路径可以使用 `6.15.1`，Webpack / Rspack 路径可以使用 `6.15.2`，Verdaccio 可以使用 `6.15.3`，老 Request 路径甚至可以运行 `6.5.5`。**

而如果你真正关心的是 **最终发布到 SAP Commerce Cloud 的 Spartacus Storefront 在用户 Chrome 浏览器里究竟有没有执行 `qs`、如果有到底是哪一版**，那就不能再看 `npm explain` 了，下一步应该直接检查 Angular production bundle；这是判断你前面那个 `qs` 安全漏洞是否真正具有 production runtime exposure 的关键一步。

[1]: https://nodejs.org/api/modules.html?utm_source=chatgpt.com "Modules: CommonJS modules | Node.js v26.8.1 Documentation"
[2]: https://docs.npmjs.com/cli/v12/commands/npm-explain/?utm_source=chatgpt.com "npm-explain | npm Docs"


哪个模块执行了 require('qs')，Node.js 就以这个模块所在目录为起点查找 node_modules/qs；找到最近的一份就用哪一份。Node.js 官方明确说明，裸包名的解析会从调用模块所在目录开始逐层向父目录查找 node_modules。(Node.js)

如果项目工程引入多个版本的 qs，运行时使用哪个版本的代码？

紫薇堂堂主

编程语言

Node.js模块解析机制下，Spartacus工作区中不同工具链实际加载不同qs版本：Express5路径用6.14.2，Karma/body-parser用6.15.1，Webpack/Rspack用6.15.2，Verdaccio用6.15.3，request用6.5.5。npm仅构建依赖树，运行时由模块解析位置决定版本。需检查Angular生产bundle确认浏览器端实际暴露的qs版本，以评估CVE风险。

代码解释

4核4G3M云服务器 新用户低至38元/年！

lighthouse

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Node.js模块解析机制下，Spartacus工作区中不同工具链实际加载不同qs版本：Express5路径用6.14.2，Karma/body-parser用6.15.1，Webpack/Rspack用6.15.2，Verdaccio用6.15.3，request用6.5.5。npm仅构建依赖树，运行时由模块解析位置...

如果项目工程引入多个版本的 qs，运行时使用哪个版本的代码？-腾讯云开发者社区-腾讯云

如果项目工程引入多个版本的 qs，运行时使用哪个版本的代码？

如果项目工程引入多个版本的 qs，运行时使用哪个版本的代码？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐