node_modules 里多了个包，直接翻 lockfile 有点费劲时，可以在项目根目录跑：
npm explain <package-name>
比如 npm explain debug，它会把依赖链打印出来，能看出是哪个直接依赖或传递依赖带进来的。npm why <package-name> 也是同一个用途。
环境：npm 7+，命令只读取当前项目的依赖信息，不会改 package.json 或 lockfile。找不到包时先确认是在正确的项目目录里。
补一个小区别：npm explain 更适合追“为什么会装进来”，如果想看当前实际装了哪些版本，可以再跑：
npm ls debug --all
前者看依赖链，后者看安装树，遇到重复版本或 invalid 时更直观。两条都建议在项目根目录执行。
Zoe_JayLv1#1 补一个小区别：
npm explain更适合追“为什么会装进来”，如果想看当前实际装了哪些版本，可以再跑：npm ls debug --all前者看依赖链，后者看安装树，遇到重复版本或
invalid时更直观。两条都建议在项目根目录执行。
如果项目用了 npm workspaces，也可以限定到某个 workspace，避免把其他包的依赖链混进来：
npm explain debug --workspace packages/web
packages/web 换成实际的 workspace 名或路径，在项目根目录执行就行。monorepo 里排查“到底是哪个子项目带进来的”时会更容易定位。
HosuLv1#2 如果项目用了 npm workspaces，也可以限定到某个 workspace，避免把其他包的依赖链混进来：
npm explain debug --workspace packages/web
packages/web换成实际的 workspace 名或路径，在项目根目录执行就行。monorepo 里排查“到底是哪个子项目带进来的”时会更容易定位。
对，另外 npm ls 有个容易忽略的点：依赖树里出现 invalid 或缺失时，它可能仍然把树打印出来，但进程会以非零状态退出。放进 CI 时别只看输出，最好也检查退出码。
npm explain 主要回答“它为什么在这里”，不等于当前安装状态一定没问题。
NiroLv1#3 对，另外
npm ls有个容易忽略的点：依赖树里出现invalid或缺失时，它可能仍然把树打印出来，但进程会以非零状态退出。放进 CI 时别只看输出，最好也检查退出码。
npm explain主要回答“它为什么在这里”，不等于当前安装状态一定没问题。
这个退出码提醒很关键。CI 里如果还想把依赖树留成日志，可以把 npm 自己的状态单独取出来：
set -o pipefail
npm ls debug --all 2>&1 | tee npm-ls.log
status=${PIPESTATUS[0]}
exit "$status"
这是 Bash + npm 7+ 的写法；别直接用 $?，那拿到的通常是 tee 的状态。其他 shell 要用各自的管道状态语法。