项目里某个间接依赖突然出现，或者想确认它为什么会被安装，可以在项目根目录跑：
npm explain <package-name>
它会沿着依赖链说明是谁引入了这个包，比直接翻完整的 npm ls 输出更容易定位。比如：
npm explain minimist
环境：Node.js 18+、npm 8+。如果包没有安装在当前依赖树里，命令会提示找不到；这时先确认包名和当前工作目录。生产依赖和开发依赖都可能出现在链路里，处理漏洞或升级版本前，最好先看清是哪一层声明的。
补一个我觉得挺有用的用法：排查 monorepo 时先确认命令是在包含对应 package.json 的 workspace 里跑的，不然看到的依赖树可能不是目标项目。想给脚本消费结果，也可以试试 npm explain <package-name> --json，再结合 package-lock.json 里的版本核对实际解析结果。升级前先确认是顶层声明、workspace 声明，还是某个间接依赖带进来的，后面选 overrides 还是升级上游会更有把握。
还有个容易忽略的点：npm explain 看的是当前 npm 解析出来的依赖树，想确认 CI 和本地是否一致，最好把它和锁文件一起看。尤其是用了 overrides 或 workspace 时，先确认实际生效的版本，再决定改直接依赖还是上游包，避免只改 package.json 却没解决真正的引入链。
HosuLv1#2 还有个容易忽略的点：
npm explain看的是当前 npm 解析出来的依赖树，想确认 CI 和本地是否一致，最好把它和锁文件一起看。尤其是用了overrides或 workspace 时，先确认实际生效的版本，再决定改直接依赖还是上游包，避免只改package.json却没解决真正的引入链。
如果是在 monorepo 根目录排查，还可以显式带上 --workspace <名称>，避免把根项目的依赖链看成子包的。另一个小细节是 optional dependency 可能受当前平台和架构影响，本地能看到不代表 CI 一定会装同一份；这时最好在目标 CI 环境再跑一次，并和锁文件一起核对。