SemVer 范围与依赖解析：^ 和 ~ 的边界、锁文件、扁平与嵌套
package.json 里的版本范围只回答一个问题：这个依赖允许被升到哪个版本。把它展开成区间、区分「范围」与「锁文件」、理解解析器是扁平还是嵌套，才能解释为什么本地跑得好好的代码在 CI 上炸了。
- SemVer 规范：
- npm
package.json字段说明：
范围写法：以 1.2.3 为基准
| 写法 | 展开后的区间 | 允许的变化 |
|---|---|---|
1.2.3 | 1.2.3 | 精确，不允许任何升级 |
~1.2.3 | >=1.2.3 =1.2.3 =0.2.3 =1.2.0 =1.2.0 =1.2.3-alpha。多段区间可以用 ` |
"dep": "1.2.7 || >=1.2.9 <2.0.0"
锁文件：范围说「可接受什么」，锁文件说「这次装了什么」
范围是声明式的约束集合，本身不指定具体版本。没有锁文件时，npm install 每次都可能解出不同的依赖树——今天装 1.2.3，明天上游发了 1.2.4 就变成 1.2.4。
锁文件把每个包的精确版本和完整性哈希记下来，哈希同时用于校验包内容有没有被篡改。CI 上用冻结模式安装，跳过版本解析，严格按锁文件落地：
npm ci # 严格按 package-lock.json 安装
yarn install --frozen-lockfile # 锁文件与 package.json 不一致时直接失败
pnpm install --frozen-lockfile
cargo build --locked
是否提交锁文件取决于产物形态：应用必须提交，否则部署不可复现；库通常不提交，因为库的使用者会用自己应用的锁文件解析版本，提交锁文件等于把某一份具体解析结果强加给下游，还可能掩盖依赖声明的真实约束是否过宽。
解析策略：单一版本 vs 嵌套
| 策略 | 行为 | 代表 |
|---|---|---|
| 单一版本 / 扁平 | 整张图里同一个包只保留一个版本 | Go modules、Cargo、Maven |
| 嵌套 | 同一包的不同版本各自装一份 | npm、yarn、pnpm |
扁平策略下出现版本冲突时，各工具的处理不同：Go modules 直接报错，要求显式提升被依赖方的版本；Maven 走「最近优先」，取依赖树里离根最近的那个版本，静默选一个。
npm 做的是「最近优先」加提升（hoisting）：从根开始深度优先解析，能提升到顶层的版本就提升上去，形成扁平结构；只有和顶层版本冲突的才嵌套在子依赖下面。副作用很具体——同一个包在 node_modules 里出现两份实例时，instanceof 判断会失败，模块级的单例状态不再共享，打包体积也跟着涨。排查时可以先看谁被装了多份：
npm ls
冲突背后是 SAT，报错信息是它的翻译
依赖解析在形式上属于布尔可满足性问题（SAT）的变体：给定一批包、每个包的可选版本和各类约束，找一个满足全部约束的赋值。候选组合随依赖数量指数增长，问题是 NP 难的，穷举不现实。现代解析器用回溯加启发式：PubGrub（Cargo、pub 采用）做冲突驱动的版本推导，也有的用 CDCL 或贪心加冲突回退。PubGrub 最有价值的产出是人类可读的冲突解释——它会告诉你哪个约束由哪个包引入，以及两条链在哪一个版本上互斥，而不是丢一句「无法解析依赖」。
降低冲突概率
- 直接依赖少而精，传递依赖的面积自然小。
- 用
resolutions/overrides强制统一某个传递依赖的版本。 - 优先选生态采用面广的包，版本约束通常更收敛。
- 定期升级、小步快跑，别把几十个 MAJOR 攒在一次升级里。
- 让 Dependabot / Renovate 开 PR，CI 负责把关。