npm install核心流程分三阶段：先由lib/commands/install.js入口调度arborist.reify()解析依赖树，再通过registry.fetch()获取包元数据并用pacote.extract()下载解压，最后按SemVer求解版本交集、执行扁平化安装并更新package-lock.json。
要看 JS 中 npm 依赖的源码解析与底层实现，关键不是从头读完全部代码，而是抓准入口、理清主线、分层验证。核心路径就三条：命令执行链、依赖解析逻辑、安装落地机制。
从 npm install 命令入口开始追踪
npm 的主逻辑集中在 lib/install.js（v9+ 版本在 lib/commands/install.js），这是所有 npm install 行为的起点。它不直接下载，而是调度一系列生命周期任务：
- 先调用
arborist.reify()—— 这是 npm 7+ 引入的依赖树管理器，负责构建、比对、修正 node_modules 结构 - 再触发
registry.fetch()（通过npm-registry-fetch模块）向 registry 发起 HTTP 请求获取包元数据和 tarball 地址 - 下载后交由
pacote.extract()解压并写入磁盘，同时更新package-lock.json
重点看依赖解析怎么“算出版本”
版本计算不是简单匹配，而是基于语义化版本（SemVer）做兼容性求解。真正干活的是 semver 和 node-semver 模块：
-
semver.validRange('^1.2.3')解析范围字符串，转成可比对的结构 -
semver.satisfies('1.5.0', '^1.2.3')判断某个具体版本是否满足约束 - 当多个依赖要求同一包的不同范围（比如 A 要
lodash@^4.17.0，B 要lodash@~4.18.0），arborist 会尝试找出交集版本；失败则报ERESOLVE错误
理解 node_modules 是怎么“扁平又嵌套”的
npm 并非纯扁平或纯嵌套，而是一种优先提升 + 局部覆盖策略：
- 顶层
node_modules尽量放所有兼容版本的包（dedupe） - 若某子依赖明确要求一个不兼容的版本（如
react@17和react@18冲突），该版本会被装进其父模块自己的node_modules下 - 模块加载时按 Node.js 规则向上查找：
require('x')先找当前目录node_modules/x，再逐级往上，直到项目根node_modules
快速验证源码逻辑的小技巧
不用 clone 整个 npm 仓库也能看真实行为：
- 运行
npm install --loglevel silly，输出里会打印每一步 resolve、fetch、link 的详细路径和参数 - 加
NODE_OPTIONS=--inspect启动调试，用 Chrome DevTools 断点进lib/commands/install.js - 查某包安装细节：执行
npm view lodash dist.tarball看它实际从哪下、用什么压缩格式
