3.2 依赖解析的幂等性

3.2 依赖解析的幂等性

本节摘要："可复现"其实是两个强度不同的命题：同一份输入在不同机器解出同一方案（求解幂等），以及同一份输入重复执行得到同一落盘结果（执行幂等）。锁文件把第一个命题做实了大半，但两个命题各有真实的失效条件——远端删除、哈希漂移、环境差异脚本。本节把担保边界勘验清楚：知道工具承诺到哪里，才知道自己的制度该从哪里接管。

从两个命题的区别说起

先把概念掰直。求解幂等说的是：给定同样的清单加锁文件，任何人在任何机器上解析，得到的版本方案完全一致。执行幂等说的是：拿定这套方案，安装一万次，落盘结果与第一次完全相同。两个命题一前一后，前者靠锁文件担保，后者靠安装器的执行纪律担保——而两者的失效方式完全不同，混为一谈就会误判事故。

用一个判定句记住分野：求解幂等坏了，症状是"装出来的版本变了"；执行幂等坏了，症状是"同样的版本装出来的行为不一样"。前者常见，后者罕见但更毒。

求解幂等：锁文件担保了什么

有锁文件在场且自洽时，安装器走照抄模式，求解过程根本不发生——这时讨论求解幂等已经没有意义，锁文件本身就是幂等的物化。真正需要勘验的是锁文件缺席或失洽的场景，那里藏着三个真实的失效条件。

失效条件一：候选集合漂移。 2.1 节已经论证：解析是带回溯的搜索，候选版本集合随远端演化。没有锁文件的团队，每一次全新安装都是一次新的搜索——上个月的方案在今天未必复现。这是"删锁重装"被列为高压线动作的算法根源。

失效条件二：解析顺序敏感。 提升规则先到先得（2.3 节），而解析顺序受清单声明顺序、遍历策略影响。两份内容相同的清单若行序不同，在无锁状态下可能解出不同布局。锁文件连布局关系一并记录（3.1 节第三道核验），才把这条缝也封住了。

失效条件三：范围边界的解读差异。 同一份清单换一个工具解析（比如 Npm 与 Yarn 互读对方的清单），在区间边界处可能选出不同版本——各家求解策略与平局规则并不一致。这就是"一个仓库两套工具混用"必然出事的原因，也是第七章迁移时必须换锁的深层理由。

图 3-2 幂等性的担保边界与失效条件

执行幂等：照着锁文件装也会翻车的三种情形

执行幂等的失效更少见，但每一种都值得单独勘验，因为它们的排障方向完全不同。

情形一：远端删除。 锁文件记录的取件地址指向远端的某个压缩包，哪天该版本被发布方从仓库下架（无论出于撤版还是恶意），照抄模式也会取件失败。锁文件能冻结"当时解到什么"，却管不住远端的货架。私有源正是为此存在的防线——第六章 6.3 会完整勘验固化方案。

情形二：哈希漂移。 极端案例里，同一版本号对应的压缩包内容发生过变化（发布方覆盖发布、镜像同步错位）。此时不同时间下载的同"版本"内容不同，照抄模式装出行为不一致的环境。完整性哈希在这种情形下从防线变成报警器——校验失败本身就是重要信号，说明供给链出了问题，而不是安装器坏了。

情形三：环境差异脚本。 版本一致、哈希一致，但包的安装脚本读了环境信息（检测平台、探测系统库），在不同机器上走出不同分支。这不是包管理器的错，但它让"同版本同行为"的直觉失效。排障心法：怀疑到这一层时，把安装日志里脚本阶段的输出逐行对齐，分歧点往往一目了然。

幂等失效的快速分诊表

把两个命题、六种失效放进一张分诊表，事故时按症状查行：

分诊表的价值在于阻止一种最常见的浪费：把执行幂等的问题当成求解问题处理——比如哈希校验失败后反复删锁重装，不仅无效，还会顺手毁掉唯一的物证。

把幂等担保写进流水线

担保边界清楚了，接着把"验证担保还在"变成自动化。三个轻量检查可以挂进流水线，成本都不高。检查一：双装对比。 同一提交连续跑两次严格安装，比对依赖目录清单一致——这是执行幂等的直接验证。检查二：锁文件零漂移。 安装后检查锁文件有无变更，有变更即失败——确认安装全程没有回写，杜绝隐性求解。检查三：关键产物指纹。 对构建产物计算指纹，连续两次构建比对——它顺带覆盖了"同版本行为不一致"一类的问题，指纹一旦漂移，说明有依赖在环境差异上走了分支。

三个检查合起来是一台幂等监测仪：任何一处亮红灯，都意味着本节某个失效条件被触发，按分诊表定位即可。工程上的担保从来不是声明出来的，是回归出来的——把担保写成会失败的红灯，它才真正存在。

两个经典疑案的幂等裁决

用分诊表裁两桩流传极广的"悬案"，检验一下这套方法是否好用。疑案一：同一分支，两条流水线装出不同结果。 第一反应应是查求解幂等的三个失效条件——锁文件是否在场且入库、是否有人本地生成了未提交的锁变更、是否有 job 混用了不同工具。实际排查中，最常见的真凶是缓存键没绑定锁文件哈希，旧缓存让某个 job 用了过时的依赖副本——症状像求解漂移，根因在执行层，分诊表防的正是这种错位。疑案二：重装之后问题消失了，要不要当它没发生过？ 要管。重装等价于把落盘复位到锁文件描述的状态，问题消失说明此前磁盘上存在与锁不一致的残缺状态——谁改的、为什么漂移，要留痕。正确动作是记录现场（当时的目录状态与日志），再复位，最后在团队日志里留一条"已知漂移"备案。悬案可以结，账不能烂。

本节要点回顾

• 可复现是两个命题：求解幂等（版本一致）由锁文件担保，执行幂等（落盘一致）由安装纪律担保，失效方式不同；
• 求解幂等三失效：候选漂移、解析顺序敏感、范围解读差异——分别对应锁入库、同框提交、不混用工具三条守则；
• 执行幂等三失效：远端删除、哈希漂移、环境差异脚本——分别对应私有源、供给链警报、日志对齐三种处置；
• 症状分诊先行：先分清"版本变了"还是"行为变了"，再动手，防止排障毁证据；
• 合流结论：可复现等于锁管版本、纪律管落盘、仓库管供给，三者缺一不可。

机制边界勘验完了，下一节进入本章最实用的实战：当两个人同时动锁文件，合并冲突现场该怎么一步步处置——为什么手改冲突标记是最差选择，正确流程只有三步。