4.1 核心安装步骤剖析
4.1 核心安装步骤剖析
本节摘要：一次安装的完整生命周期可以拆成五个阶段：预检、解析照抄、取件、落盘链接、生命周期收尾。本节逐阶段勘验，每阶段配一段真实日志形态，训练"从报错反推失败阶段"的诊断能力——安装类问题的排障效率，取决于你能否在看到报错的第一眼就定位阶段。
从一段完整日志开始
先把一次典型安装的输出完整摆出来，作为本节的勘验底稿：
$ npm install npm warn config production Use `--omit=dev` instead. ⸩ reify:lodash: timing reifyNode:node_modules/lodash completed in 212ms added 36 packages, and audited 37 packages in 3s found 0 vulnerabilities
看似平淡的输出，其实浓缩了五个阶段。reify 这个词是关键词——它是安装器对"把理想状态落成现实"这一阶段的内部称呼，日志里大量 timing 行都发生在这一阶段。而 added 与 audited 两行分别对应落盘完成的统计与安全审计的收尾。能从日志词汇反推阶段，是排障的第一项基本功。
五阶段逐项勘验
阶段一：预检。 安装器读配置、确认清单与锁文件的状态。第三章已经勘验过这里的分叉：ci 模式下失洽直接报错退出，install 模式下尝试调和。预检失败的特征是报错发生在任何下载动作之前——输出里没有进度条、没有包名，只有配置或文件层面的抱怨。看到这种形态，先查清单与锁文件，不要去怀疑网络。
阶段二：解析照抄。 确定每个包的精确版本与来源。锁文件在场且自洽时，这一阶段几乎是纯查表，耗时可以忽略；失洽或无锁时退回求解模式，复杂依赖图可能在这里停留明显的时间。2.1 节的搜索树就是这一阶段的内部实况。
阶段三：取件。 从缓存或远端获取压缩包。理想路径是缓存命中：包管理器把下载过的包存在用户级缓存目录里，同版本第二次取件完全不碰网络。缓存未命中才走远端下载，下载完成后立刻重算完整性哈希与锁文件记录比对——第六章会把这一步的安全意义讲透。
阶段四：落盘链接。 把压缩包内容安置到 node_modules 的最终位置。按 2.3 节的布局规则，先落顶层、冲突降级嵌套。ci 模式在这一阶段之前会先清空旧目录，保证无历史包袱；install 模式则就地增删，能不动的不动。现代安装器在此阶段大量使用链接与写时复制技术，从缓存"链接"而非"复制"文件——这是 4.4 节实验的性能来源。
阶段五：生命周期收尾。 执行依赖包自带的安装期脚本（编译、配置、生成产物），跑完安全审计，输出统计。报错若发生在这一阶段，特征是包文件已经就位、但包名相关的脚本输出出现在日志尾部——此时问题多半出在脚本层（编译失败、平台不匹配），而不是下载层。下一节就深入这个阶段。
图 4-1 安装流水线五阶段与报错形态对照
用两次人为故障训练定位
空口无凭，制造两次故障来练定位。故障一：锁文件失洽。
$ npm install lodash@4.0.0 --no-save # 只动锁文件语义路径 # 或直接手工编辑 package.json 改版本范围但不更新锁 $ npm ci npm error `npm ci` can only install packages when your package.json and npm error package-lock.json are in sync. Please update your lock file.
报错文本直接点名清单与锁不同步——阶段一的典型形态，处置是按 3.3 节流程重生成锁文件。故障二：模拟脚本阶段失败（用一个声明了非法安装脚本的包），观察日志尾部出现包名相关的执行输出后才报错——阶段五的典型形态。两种报错形态肉眼可辨，训练两轮后，你看到安装报错的第一反应就会从"重装试试"变成"这是第几阶段的问题"。
日志勘验进阶：让安装器自己交代耗时
阶段定位还能更精细——让安装器输出计时报告，把"哪一步慢"从感觉变成数据：
$ npm install --timing # 输出末尾的计时报告按阶段与包名展开： # 理想树构建行是解析耗时，reify 聚合行是落盘耗时， # 逐包的 reifyNode 行能揪出最慢的那几个包
读这份报告有个固定套路：解析段耗时占比高，去查依赖图复杂度与约束冲突；取件段占比高，去查缓存与网络；落盘段占比高，去查磁盘与杀毒扫描——Windows 环境里实时防护对海量小文件的扫描是著名的隐性开销，把项目目录加入白名单常常立竿见影。
顺带回答那个万年疑问：为什么"删了重装"经常能修好问题？因为落盘阶段是幂等的——清空后的全新落盘必然与锁文件一致；而就地更新模式遇到此前中断留下的残缺状态，可能选择"保留"错误现场。重装修好的从来不是玄学，是把目录强制复位到已知状态——这也正是 ci 命令"先清后装"的设计动机。
流水线的三种变体：短路的艺术
五阶段是完整形态，工程里常见的变体其实都是"短路某些阶段"。变体一：离线安装。 禁止网络访问后，取件段只走缓存——阶段三被压缩，速度与确定性同时提升，代价是缓存必须齐全（4.4 节实验的 C 组就是这个形态）。变体二：工作区安装。 一次安装统管仓库内全部子包，解析段把所有子包的约束合并求解，落盘段统一布局——阶段二与四的范围从"一个包"扩成"一张图"（5.1 节）。变体三：强制重建。 跳过缓存的安装与重链，专治"目录状态可疑"的现场——它把阶段四完整重跑一遍，等价于对落盘做人工复位，是排障工具箱里的重锤。
识别变体的价值在排障：知道当前命令短了哪个阶段，报错的搜索范围立即缩小一圈。离线安装报错别去查网络，重建报错别去查锁——阶段被短路的地方，恰是排除项。
本节要点回顾
- 五阶段全景：预检、解析照抄、取件、落盘链接、生命周期收尾——reify 与 added、audited 等日志词汇都能映射回阶段；
- 报错形态即路标：无包名的报错查清单锁、网络类报错查取件、包名脚本输出在尾部查生命周期；
- 落盘阶段的模式差异：ci 先清后装、install 就地增删，这解释了"重装能修好一类问题"的真实机理；
- 链接优于复制：现代安装器落盘大量使用链接技术，是 4.4 节缓存实验的机制基础；
- 日志完整性纪律：流水线保留完整安装输出，截断日志会抹掉阶段特征。
流水线走完一遍，下一站停在能力最强也最危险的一站：生命周期脚本——它让每个包在安装时获得执行代码的权力，也正因如此，它是第六章供应链攻防的必经之地。