1 篇博文 含有标签「npm」

在一次前后端同仓的多包项目部署时，部署日志里 npm audit 输出 3 个 high 漏洞，顺着日志把它记到了后端名下——修完才确认这 3 个 high 全在前端包树里，后端从始至终是另一组 moderate。

在开发 AI运营 时遇到此问题——基于大语言模型的智能分析平台，自动洞察市场趋势、用户行为与销售数据；前端在仓库根目录、后端在 server/ 目录，同仓多包分开部署。

TL;DR​

npm audit 的摘要行只有数量、不带路径；部署流顺序执行多个目录的 npm install 时输出串联在一起，摘要无法区分归属。解法：用每棵包树的唯一指纹——audited N packages 的 N——先对号入座，再用 package.json 的 overrides 钉住有漏洞的传递依赖，二次部署两端归零。

问题现象​

部署脚本先后在前端（仓库根）和后端（server/）执行 npm install，日志混在同一股输出里：

# 部署流输出（摘要行不带路径）
added 546 packages in 41s
found 3 high severity vulnerabilities

added 372 packages in 24s
found 4 moderate severity vulnerabilities

交接记录把「3 high」归因到了 server/。按这个方向去查后端依赖链，怎么都对不上——server/ 的 audit 无论在本地还是服务器跑，结果都是 4 moderate，从没出现过 high。「部署日志看得见、归属对不上」是混合部署流的常见病，此前踩过的前端部署后线上未更新也是这一类。

根因​

npm audit 摘要行只有「found X vulnerabilities」，不带目录信息；紧挨着的 audited 546 packages 也很少有人下意识当成归属线索。两棵包树规模差异巨大（546 vs 372），这恰好是唯一稳定的指纹。

前端仓库根装的是 Vite + React + Ant Design Pro 全家桶，包树大；@ant-design/pro-components → @ant-design/pro-layout 引用了旧版 path-to-regexp，这正是 3 个 high 的来源。后端 server/ 是 Express + tsx 的精简依赖树，唯一的问题是 tsx → @esbuild-kit/core-utils → 旧版 esbuild 这条 moderate 链。

解决方案​

步骤 1：按 audited N 对目录​

在本地各目录分别 npm install（或直接读部署日志的 added N packages），记录包树规模：

cd <repo-root> && npm install 2>&1 | tail -2   # added 546 packages ...
cd server      && npm install 2>&1 | tail -2   # added 372 packages ...

部署日志里 found 3 high 紧跟在 added 546 后面 → 前端；4 moderate 跟在 added 372 后面 → 后端。归属定对了，后面才不用白跑。

步骤 2：展开漏洞链​

npm audit                # 看 Path 字段，完整依赖链
npm ls path-to-regexp    # 或反查某个包被谁依赖

前端输出确认链路：@ant-design/pro-components → @ant-design/pro-layout → path-to-regexp（旧版本，3 high）。

步骤 3：用 overrides 钉住传递依赖​

前端仓库根 package.json：

{
  "overrides": {
    "path-to-regexp": "^8.4.2"
  }
}

后端 server/package.json（顺带把 tsx 升到新版）：

{
  "overrides": {
    "@esbuild-kit/core-utils": {
      "esbuild": "^0.25.12"
    }
  }
}

overrides 支持嵌套写法，只影响指定父依赖之下的子依赖版本——比全局覆盖一个包名更精准。

步骤 4：重装验证​

rm -rf node_modules package-lock.json && npm install && npm audit

两端重跑部署后，audit 均为 0 vulnerabilities。

常见问题​

npm audit fix 跑了为什么漏洞还在？​

npm audit fix 只会升级 semver 允许范围内的版本。漏洞出在传递依赖上、且被上层包的版本范围钉死时，fix 改不动它，需要用 package.json 的 overrides 强制钉版本，然后重新 npm install。

怎么定位 npm audit 报的漏洞在哪条依赖链上？​

看 npm audit 完整输出的 Path 字段，它列出从直接依赖到漏洞包的完整链路；也可以用 npm ls <包名> 反查依赖方。摘要行只有数量，不带任何路径信息。

多包项目的 npm audit 结果怎么对应到具体子项目？​

部署日志的摘要不带目录名，按各目录安装时 added N packages / audited N packages 的包树规模对号入座即可。在本地分别对每个目录 npm install 一次，记录各自的 N，之后就能稳定对应。