nvm、Node、Yarn 放在一起时，版本边界最好早点说清楚
· 阅读需 3 分钟
Node.js 项目最容易让人产生一种错觉：只要把 Node 装上、包管理器装上，环境就算齐了。可到了 2020 年左右，团队里同时使用 nvm、Node、Yarn 已经很普遍，这时候真正容易出问题的，不再是某个工具会不会装，而是它们之间的版本边界有没有讲清楚。
很多安装报错、依赖异常、脚本运行不一致，最后都能追到这层边界上来。
我后来最常见到的三种混乱
1. Node 版本是切了，但 Yarn 还在用旧环境
大家以为切了 nvm 版本，一切就会自动跟着对齐。实际上，不同 shell、不同终端会话、不同脚本入口下，工具链感知到的环境不一定完全一致。
2. 团队里每个人都能跑，但版本组合不一样
表面上看项目是“可运行”的，实际上有人用 Node 14，有人用 16，Yarn 版本也各不相同。
一旦 lockfile、原生模块或某些脚本行为对版本敏感，问题就会陆续冒出来。
3. CI、服务器、本地三套环境没有统一口径
本地跑得过，不代表 CI 能过；CI 能过，也不代表服务器上脚本就一定一致。
如果版本策略只存在于开发者脑子里，工具链迟早会暴露不一致。
我后来更愿意先约定什么
在项目开始阶段，我会尽量把这些事情先说明白：
- 项目主要支持哪几个 Node 版本
- 团队默认使用哪种包管理器
- Yarn 版本是否需要锁定
- 本地、CI、服务器是否使用一致的 Node 主版本
这些约定越早写清楚，后面的环境问题越少。
为什么这是“边界问题”
因为 nvm 负责的是版本切换，Node 负责的是运行时，Yarn 负责的是依赖安装和脚本入口。
它们彼此有关，但职责并不相同。
一旦团队把职责混在一起，就容易出现这样的误解：
- 以为切了 Node 就等于一切都同步了
- 以为 Yarn 报错一定是 Yarn 本身的问题
- 以为 lockfile 冲突只是代码问题
其实很多时候，根因只是版本边界没先说清楚。
小结
Node 工具链最烦人的地方，往往不是某个工具复杂，而是多个简单工具叠在一起之后，团队没有形成共同口径。
我后来对这件事越来越保守：nvm、Node、Yarn 可以一起用，但版本边界最好越早越明确。这样环境问题才不至于反复吞时间。