node_modules 里看到一个陌生包时，可以先让 npm 解释它为什么会被安装。环境：Node.js 16+、npm 8+，在项目根目录执行：
npm explain minimist
把 minimist 换成实际包名，输出会列出依赖它的上游包以及版本范围。遇到安全扫描提示间接依赖时，这比只看一整棵 npm ls 更容易定位该升级哪个直接依赖。
如果同一个包装了多个版本，也可以先跑：
npm ls minimist
一个负责看安装路径，一个负责解释来源，搭配起来比较清楚。两个命令都不会修改 lockfile。
安全告警场景里，顺着 npm explain 找到直接依赖后，优先升级这个直接依赖。实在等不到上游修复时可以临时用 overrides 锁住间接依赖版本，不过最好配合测试跑一遍；强行跨大版本覆盖，可能和上游声明的版本范围不兼容。
如果项目用了 npm workspaces，排查时还要留意命令执行的位置。可以在仓库根目录用 npm explain minimist -ws 看各 workspace 的依赖关系；只在某个包目录里查，可能会漏掉其他 workspace 的引入。确认来源后再改直接依赖或 overrides，最后把 lockfile 一起检查一下。
雾很大Lv1#2 如果项目用了 npm workspaces，排查时还要留意命令执行的位置。可以在仓库根目录用
npm explain minimist -ws看各 workspace 的依赖关系；只在某个包目录里查，可能会漏掉其他 workspace 的引入。确认来源后再改直接依赖或overrides，最后把 lockfile 一起检查一下。
还有个小细节：扫描器点名了某个版本时，可以直接查 npm explain [email protected]，比只写包名更容易把多版本链路对上。确认来源后再改直接依赖或 overrides，别直接手改 node_modules；需要让 lockfile 变化时再单独检查 diff。