1. Node 与 Npm 版本对应

这是一个必知必会的问题，尤其是对于维护那些老掉牙、一坨坨、非常大的有着长期历史的老破大工程。

1.1. package-lock.json 版本

首先你要会看项目的 package-lock.json 文件中的 lockfileVersion 版本号，这对于 NPM 安装来说至关重要。

• { lockfileVersion: 1 } 对应 Node 版本: 8, 10, 12, 14
• { lockfileVersion: 2 } 对应 Node 版本: 15, 16, 17 - 开发界约定基数版本为非稳定
• { lockfileVersion: 3 } 对应 Node 版本: 18, 20, 22

1.2. package-lock.json 说明

1. 你可能会问为什么版本对不上也能构建成功，那要是完全的不兼容，估计 NPM 要被人喷死了。兼容性肯定是存在的，但是兼容到什么程度完全取决于你的项目依赖包“有没有坑”。
2. 其次你可能还想知道 package-lock.json 为什么这么重要，这里有个决定性的东西非常关键。先想想一个包如何保障在每台机器上安装绝对的相同！

NPM 是通过 lock 文件中记录的 sha512散列值(hash)确定这个包是否是预期的包。

2. 如何切换 Node 版本

2.1. package.json 中的 deploy

项目的 package.json 中的 deploy 字段为发布系统识别配置，除了 node 版本切换，还支持包管理器切换、项目脚本钩子能力(beta.1 阶段)

{"name": "AppName","deploy": {"node": "18.20.5",         // 指定 node 版本"packager": "pnpm@9.15.0"  // 指定包管理器}
}

3. 常见问题

3.1. node14升级 node16常见问题

1. 依赖冲突问题；node14 以前没有 "依赖版本配对校验" 功能，对应着 package.json 中的 👉🏻 peerDependencies ，升级到 node16 后问题暴露，构建失败！
2. 对应的解决方案有两个：

• • 根据 NPM 安装日志解决依赖版本冲突；比较直观的解决办法。
  • 添加 legacy-peer-deps=true到项目根目录中的 .npmrc文件中；比较暴力(保守)的解决办法 -- 由于开发同学也吃不准如何“深入解决”依赖版本关系，切升级成本大，同时会带来新的风险(改动即风险)，相当于以为 node14 的策略运行安装机制！