装 Node.js 这件事，很多人第一次做的时候觉得「官网下个包，下一步下一步就完事了」，等到手上同时维护两三个项目、每个项目锁的 Node 大版本还不一样，才发现整台机器只有一个全局 node 有多难受——老项目跑不起来，提示语法不认识；新项目又要求某个较新的运行时，来回卸载重装，装完还忘了当时装的是哪个版本，全局装的命令行工具也一并没了。这篇 nvm 下载与安装全指南，就是把 Windows 和 macOS 两条线上的安装、配置、切版本、踩坑全部摊开讲一遍。nvm 全称 Node Version Manager，是一个纯粹的版本管理工具，它干的事情很单一：让你在同一台机器上装多个 Node.js 版本，并且能在一条命令之内切换。它适合刚配环境的新手，也适合手上挂着多个仓库、需要在不同运行时之间来回跳的老手；只要你写前端、写 Node 服务、或者维护一些带历史包袱的构建脚本，这个工具基本属于必备件。下面按我自己的实际配置顺序走一遍，中间会穿插一些只能靠踩坑才记得住的细节。
1. 先搞清楚两条产品线：nvm 在 Windows 和 macOS 上根本不是同一个东西
这是新手最容易栽的第一个坑。搜「nvm 安装」，出来的教程一半是 macOS/Linux 的 shell 脚本方案，一半是 Windows 的 exe 安装包方案，两边的命令长得像但行为不一样，配置文件格式也完全不同。照着 A 的教程在 B 的机器上敲，报错能让你怀疑人生。所以动手之前，先把这几件事分清楚，后面能省掉一大半排查时间。
1.1 同一个名字，两套实现
macOS 和 Linux 上通用的那个叫nvm-sh，本质是一个纯 shell 脚本，源码 clone 到~/.nvm目录，靠在你的 shell 配置文件里 source 一个nvm.sh来注入函数。它的切换原理是修改 PATH 环境变量，把~/.nvm/versions/node/vX.Y.Z/bin顶到最前面去，所以切换是「逻辑切换」，磁盘上多个版本是并存的，互不干扰。
Windows 上那个叫nvm-windows，是另一个作者用 Go 语言重写的独立项目，跟 nvm-sh 没有代码关系。它的切换原理完全不同：它在你指定的位置建一个叫nodejs的目录符号链接，指向具体的版本目录，然后把nodejs这个目录塞进系统 PATH。切版本的时候，它其实是在删掉旧链接、建一个新链接。理解这一点非常关键，后面 Windows 上那一堆「拒绝访问」「权限不足」的报错，根子全在这儿。
Windows 上还有个叫nvs的项目，功能相近但生态小得多，公司内部如果没统一要求，我一般不建议选，社区问答里能搜到的解决方案少一大截。
1.2 和另外几种方案的横向对比
知道有别的选择，才能在团队里说服别人。下面这张表是我在几个不同规模的项目里实际用过之后的体感对比：
| 方案 | 跨版本切换 | 是否改 PATH | 项目级版本文件 | 典型适用场景 |
|---|---|---|---|---|
| nvm-sh / nvm-windows | 支持，命令切换 | 是 | 支持.nvmrc（Windows 需借助插件） | 多项目并存、需要频繁切大版本 |
| n | 支持 | 是 | 不支持 | 单人 Mac 环境，追求简单 |
| Volta | 支持，且能锁工具链 | 是 | 支持（写进 package.json） | 团队统一工具链、CI 一致性要求高 |
| 官网安装包直装 | 不支持 | 是 | 不支持 | 只跑一个固定项目、临时验证 |
我为什么最终还是回到 nvm：它出现得早，资料最多，几乎每个报错都能搜到现成答案；.nvmrc虽然简单，但约定俗成，配合nvm use就够了。Volta 的方案更优雅（把 node 和 npm 版本一起锁进package.json），但它的自动切换依赖 shell hook，某些远程终端或容器里会失灵，排查起来比较绕。所以这篇只讲 nvm，不铺开。
1.3 一个必须先确认的判断标准
动手之前问自己一个问题：我是不是只需要一个 Node 版本？如果答案是需要两个以上，装 nvm；如果只是临时跑个 demo，用完就删，那直接下官方安装包装一次反而更省事，装 nvm 属于杀鸡用牛刀，还得额外清一遍残留。
还有一点要强调：nvm 和你系统里已经装过的 Node.js 是冲突的。不是「可能冲突」，是必然冲突。因为两者都想往 PATH 里塞自己的 node 可执行文件，谁排在前面谁生效，结果就是版本显示乱跳、node -v和npm -v对不上号。所以第二步永远是先清场再装。
2. 安装前的清场：卸载旧 Node 和清理残留
跳过这一步的人，十个里至少有六个会在装完之后遇到「nvm 显示切到了 A 版本，但node -v还是 B 版本」的鬼故事。原因就是旧的安装包把node.exe或node留在了系统目录里，PATH 里它排在前面。清场这一步花不了五分钟，能省掉后面两小时。
2.1 Windows 卸载顺序
Windows 上正确的顺序是按下面的步骤，顺序错了容易留下残渣：
- 打开「应用和功能」，找到所有名字里带 Node.js 的条目，逐个卸载。如果之前装过多个版本，会看到多条记录，全部卸掉。
- 手动检查并删除残留目录：
C:\Program Files\nodejs、C:\Program Files (x86)\nodejs、%APPDATA%\npm、%APPDATA%\npm-cache。 - 打开系统环境变量设置，检查用户变量和系统变量两个地方的
Path，把任何指向nodejs、npm的条目删掉。这一步最容易被忘，因为有的人装 Node 时勾了「加入 PATH」，卸载程序并不会把它清干净。 - 打开新的命令行窗口（旧的不会重新加载环境变量），执行
where node，如果还能输出路径，说明还没清干净，回到第 3 步继续找。
where这个命令比node -v有用得多，因为它会把所有同名可执行文件的路径全列出来，你能一眼看出是哪一个在捣乱。macOS 上对应的是which -a node。
2.2 macOS 卸载与全局包备份
macOS 上旧版 Node 通常是 pkg 安装的，卸载方式不太直观，按这个顺序来：
# 列出所有 node 相关文件，先看清楚再删 ls -l /usr/local/bin/node ls -l /usr/local/bin/npm # 如果是 pkg 装的，删掉这些 sudo rm -rf /usr/local/lib/node_modules sudo rm -rf /usr/local/bin/node sudo rm -rf /usr/local/bin/npm sudo rm -f /usr/local/share/man/man1/node.1卸载前先把全局安装的包记下来，这步非常值得做。执行npm ls -g --depth=0，把输出存到一个文本文件里。后面重装完 Node，靠这份清单重新装一遍全局工具，比凭记忆一个个想去靠谱得多。我自己吃过这个亏：某次重装后忘了装某个命令行脚手架，隔了两周项目编译才报错，翻日志翻了半天才想起来是全局包没了。
2.3 目录规划上的两个硬性要求
无论哪套系统，nvm 的安装目录都有两个不能碰的红线：
- 路径里不能有中文和空格。Windows 默认把 nvm 装在
C:\Users\你的用户名\AppData\Roaming\nvm，如果你的用户名里有中文，直接改成D:\dev\nvm这种纯英文短路径。空格同理，C:\Program Files\nodejs这个默认值经常会引发一些工具脚本的解析问题，能改成C:\dev\nodejs就改。 - 不要放在需要管理员权限才能写的位置。nvm 每次装新版本都要往这个目录里写文件，如果目录归 root 或 SYSTEM 所有，普通权限的命令行会直接失败。
至于权限本身：Windows 上首次安装建议右键「以管理员身份运行」，装完之后的日常nvm install、nvm use也建议在管理员终端里做，原因后面 6.1 会展开。macOS 上则相反，不要用 sudo 跑安装脚本，脚本会在你的家目录下建~/.nvm，用 sudo 建出来的目录属主是 root，后面每次nvm install都要 sudo，非常难受。
3. Windows 实装：从安装包到第一个可用版本
Windows 这条线的步骤比 macOS 多，主要是多了一层配置文件要改。但改完之后体验很省心，值得花十分钟配好。
3.1 获取安装包
去项目的 Release 页面下载nvm-setup.exe即可，不要下nvm-noinstall.zip，那个是给需要绿色部署的场景准备的，要手动配环境变量，对新手不友好。下载完成后，如果有校验值就顺手对一下文件哈希，命令行里用certutil -hashfile nvm-setup.exe SHA256就能看，虽然这一步很多人跳过，但下载大文件时我习惯性会看一眼，尤其是从第三方镜像站点拿包的时候。
3.2 安装向导里两个必须改的地方
安装向导会问你两个路径，这两个都不能无脑点下一步：
- nvm 的安装目录：也就是存放各个 Node 版本和配置的地方。建议改成
D:\dev\nvm这类短路径。 - nodejs 的符号链接目录：安装向导里显示为「Node.js Symlink」，默认是
C:\Program Files\nodejs。建议改成D:\dev\nodejs，理由同上，避开空格。
为什么这个 symlink 目录要单独设？因为 nvm-windows 的切换逻辑是：把D:\dev\nodejs这个链接指向D:\dev\nvm\v18.20.4，而系统 PATH 里只有D:\dev\nodejs一条。这样无论你装多少版本，PATH 都只有一条记录，永远不用改环境变量。理解了这一层，你就能明白为什么不能在这两个目录里手动放任何文件——会被链接覆盖，或者覆盖链接导致切换失败。
安装完成后，务必关掉所有已经打开的终端窗口，重新开一个新的。安装程序改的是系统环境变量，已存在的终端进程读的还是旧快照。这一点我在第一次装的时候没注意，对着新窗口敲nvm version死活没反应，折腾了半小时才发现是老终端的问题。
3.3 settings.txt：整个 Windows 方案里最值得改的文件
打开 nvm 安装目录，会看到一个settings.txt。默认内容大概是两行root和path，我一般会把它补成下面这样：
root: D:\dev\nvm path: D:\dev\nodejs arch: 64 node_mirror: https://npmmirror.com/mirrors/node/ npm_mirror: https://npmmirror.com/mirrors/npm/逐行解释一下为什么这么写。root和path必须和安装时选的一致，写错了会导致nvm use找不到版本目录。arch: 64是明确指定拉 64 位包，虽然默认也是 64，但写死可以避免在某些老机器上误判。后面两行node_mirror和npm_mirror是官方支持的镜像配置项，作用是把下载地址指向一个响应更快的公共源——国内网络环境下直接连官方源下载大版本，经常卡在百分之几然后超时，改完这两个地址，下载速度通常能快一个数量级。
注意：
settings.txt的格式对空格很敏感，冒号后面要有一个空格，路径里不要带引号，也不要加任何注释行。改完保存后重开终端才生效。另外这个文件在老版本里的字段名略有差异，如果写了不生效，先执行nvm version确认版本，再去对应版本的文档里核对字段名。
3.4 装第一个版本并验证
# 查看当前 nvm 版本，确认装好了 nvm version # 列出远端可安装的版本（这一步会联网拉取列表） nvm list available # 安装一个 LTS 版本 nvm install 20.11.1 # 切换过去 nvm use 20.11.1 # 验证三件套 node -v npm -v nvm listnvm list的输出里，当前正在使用的版本前面会带一个*，这是 nvm-windows 独有的标记方式，很好认。如果node -v报「不是内部或外部命令」，别急，先看nvm list里有没有星号，再看D:\dev\nodejs这个链接目录是否存在。这两步能定位掉八成问题。
还有一个细节值得提醒：nvm list available拉的列表里有LTS和Current两栏，日常开发优先选 LTS。Current 线上的版本生命周期短，一些构建工具的原生模块还没跟上，装完可能编译报错。我自己的习惯是新项目起步用最新 LTS，等真正需要某个新特性时再单独升。
4. macOS 实装：两种装法，各有取舍
macOS 上的选择更多，我常用的有两种：官方脚本安装和 Homebrew 安装。两者都能用，但后续维护方式不一样，选之前先看清楚差异。
4.1 脚本安装的完整流程
这是最贴近官方的做法，也是最不容易出玄学问题的：
# 方式一：直接执行安装脚本 curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash如果你所在的环境对直接从远端执行脚本比较谨慎（这其实是好习惯），可以改成先下载再检查再执行：
curl -o install_nvm.sh https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh less install_nvm.sh # 先看一眼内容 bash install_nvm.sh脚本做三件事：把仓库 clone 到~/.nvm；在~/.zshrc（或~/.bash_profile，取决于你的 shell）末尾追加一段 source 代码；提示你重开终端或手动 source。
追加的那段代码长这样：
export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"第一行定义目录变量；第二行判断文件存在才 source，避免目录被误删后每次开终端都报错；第三行是可选的命令补全，加上之后敲nvm ins按 Tab 能自动补全成nvm install，日常用起来很顺手。
如果脚本执行完，重开终端后nvm仍然提示 command not found，先执行echo $SHELL看当前用的是哪个 shell。zsh 读~/.zshrc，bash 读~/.bash_profile或~/.bashrc，两者不通用。当年我换了默认 shell 却没转移配置，卡了很久才反应过来。
4.2 Homebrew 安装的差异与清理注意
brew install nvm mkdir ~/.nvmHomebrew 装完之后不会自动帮你写 source 配置，必须手动在~/.zshrc里加一行：
export NVM_DIR="$HOME/.nvm" [ -s "/opt/homebrew/opt/nvm/nvm.sh" ] && \. "/opt/homebrew/opt/nvm/nvm.sh"路径要注意区分：Apple Silicon 机器上前缀是/opt/homebrew，Intel 机器上是/usr/local。写错了就是找不到文件。
两种方式怎么选？我的实际经验是：如果你不是重度使用 Homebrew 管理一切的人，优先选脚本安装。原因是 brew 装的 nvm 在升级时可能被brew upgrade一并动到，而 nvm 的版本升级本身很轻量，未必需要跟着 brew 走；更麻烦的是，一旦哪天决定改回脚本安装，~/.nvm目录和 brew 版本会互相干扰，得先brew uninstall nvm，再清掉残留的配置行，把.zshrc里两段 source 都删干净，否则一个终端里可能出现两个 nvm 函数。
4.3 装第一个版本与默认版本设置
macOS 这边命令和 Windows 略有差别，尤其是「默认版本」这个概念：
# 直接装最新 LTS nvm install --lts # 设为默认（新开终端自动生效） nvm alias default 20 # 查看本地已装版本 nvm ls # 查看远端可安装版本 nvm ls-remote --lts # 查看当前正在用哪个 nvm currentnvm alias default 20这一步千万不能省。nvm-sh 的机制是：每次新开终端，自动激活default别名指向的版本。如果不设，某些配置下会变成没有默认版本，新开终端敲node直接 command not found，得手动nvm use一次才行。这也是从 Windows 迁过来的人最容易踩的坑——nvm-windows 有nvm on的概念帮你启用，nvm-sh 没有，靠的就是别名。
顺便说一句nvm ls-remote的输出可能很长，几百行刷屏。我一般配合管道过滤：nvm ls-remote --lts | tail -20，只看最近的几个 LTS 版本号，比在一堆数字里找眼球舒服得多。
5. 日常使用：命令对照与项目级版本锁定
装完之后真正的日常操作其实就五六条命令，但两套实现的命令名有细微差别，混着记容易出错。下面这张表是我贴在笔记里的对照表，建议存一份。
5.1 两套实现的命令差异速查
| 用途 | nvm-windows | nvm-sh（macOS/Linux） |
|---|---|---|
| 查看 nvm 自身版本 | nvm version | nvm --version |
| 列出已安装版本 | nvm list | nvm ls |
| 列出可安装版本 | nvm list available | nvm ls-remote |
| 安装指定版本 | nvm install 20.11.1 | nvm install 20.11.1 |
| 切换版本 | nvm use 20.11.1 | nvm use 20.11.1 |
| 设置默认版本 | 无直接命令 | nvm alias default 20 |
| 查看当前版本 | nvm list（带*） | nvm current |
| 卸载某版本 | nvm uninstall 18.0.0 | nvm uninstall 18.0.0 |
| 启用/停用 | nvm on/nvm off | 无此概念 |
| 全局包迁移 | 不支持 | nvm reinstall-packages <version> |
注意nvm list available这个写法：老版本的 nvm-windows 用的是nvm ls available，两个都能用，但新版本推荐前者。如果你敲了没反应，换另一种写法试试。
5.2 用 .nvmrc 把版本写进仓库
这是团队协作里性价比最高的一个小习惯。在项目根目录放一个.nvmrc文件，内容就一行版本号：
20.11.1然后nvm use不带参数执行，它会自动往下找最近的.nvmrc并切换过去。macOS 上这个能力是原生的；Windows 上 nvm-windows 本身不读.nvmrc，需要借助一个叫nvm-use的 PowerShell 脚本或第三方包，或者干脆在package.json里加一个脚本：
{ "scripts": { "node:version": "node -v" } }我在跨平台团队里推的做法更朴素：.nvmrc照放，README 里写一句「Windows 用户请手动执行nvm use 20.11.1」。虽然不够自动化，但零依赖、零成本，比强上一个团队里一半人跑不起来的自动切换方案务实。
另外记得把.nvmrc提交进版本库，不要在.gitignore里把它排掉。我见过有项目把它当本地配置文件忽略掉的，结果新人拉下来跑构建直接报 Node 版本不匹配，还得在群里问一句「你们用的哪个版本」。
5.3 全局包的跨版本迁移
nvm 的一个设计取舍是：每个 Node 版本有独立的全局包目录。你在这个版本下装的命令行工具，切到另一个版本后就没了。这个设计从隔离性上说是对的，但从使用体验上确实烦人。
macOS 上有现成的解法：
# 把旧版本下的全局包，全部重装到新版本 nvm reinstall-packages 18.20.4Windows 上没有对应命令，只能手动来：
nvm use 18.20.4 npm ls -g --depth=0 # 记下清单 nvm use 20.11.1 npm install -g 包名1 包名2 包名3这个流程我优化过一版：用npm ls -g --depth=0 --json输出成 JSON，再用一个几行的脚本提取包名，批量重装。虽然一次性工作，但如果你经常切版本，这十几行脚本能省掉不少重复劳动。写不写脚本另说，养成切完版本后确认一次npm ls -g --depth=0的习惯，比什么都管用。
5.4 npm 自身的版本也要管
Node 大版本切换的时候，npm 版本也会跟着变（npm 是跟着 Node 一起分发的）。有些项目对 npm 版本有要求，比如锁文件格式lockfileVersion在不同 npm 大版本间会变，混用会导致npm ci报错或者包解析结果不一致。
简单做法是在项目里用一个包管理器的字段声明，或者干脆记录在 README 里。如果你希望更严格地控制，可以在package.json里加上：
{ "engines": { "node": ">=20.0.0 <21", "npm": ">=10.0.0" } }engines字段默认只是警告不阻断，配合.npmrc里的engine-strict=true才会变成硬性检查。这个开关要不要开看团队情况，开了之后 CI 上能提前暴露版本不一致的问题，但也会让一些临时调试变得麻烦。
6. 报错排查实录：那些文档里不会写的坑
下面这些是我自己和同事在实际配置过程中真实遇到过的问题，按平台归类整理，每条都写了排查路径，遇到时可以直接对号入座。
6.1 Windows 上的高频问题
问题一：nvm use报exit status 1: 拒绝访问或者exit status 145。
这是出现频率最高的一条。根因是创建目录符号链接需要权限，普通终端没有。解法有三个：一是用管理员身份运行终端；二是去「本地安全策略」里给当前用户授予「创建符号链接」的权限；三是临时关掉系统的开发者模式限制。我通常直接用第一种，最省事。如果管理员终端也报错，那多半是nodejs这个链接目录被某个进程占用着——比如你开着 VS Code，它的终端或者某个插件正持有该目录下的文件句柄，把编辑器全关掉再试。
问题二：切完版本，node -v还是老版本。
按这个顺序查：先where node，看输出里有几条路径。如果出现两条以上，说明旧的 Node 没卸干净，回到第 2.1 节重做。如果只有一条但路径不对，检查系统环境变量里是不是还留着旧的nodejs路径。还有一种隐蔽情况：你在某个终端里手工set PATH过，那个终端会一直用旧快照，重开才行。
问题三：nvm install卡在下载，进度条半天不动。
先确认settings.txt里的两个 mirror 字段写对了。改完还是慢的话，可以临时用命令行参数指定：nvm install 20.11.1 --insecure（跳过证书校验，仅用于排查是不是证书链问题）。如果排查下来确实是源的问题，把 mirror 换一个公共镜像地址再试。这里提醒一句，镜像地址会变动，写进文档的固定地址过一段时间可能失效，遇到 404 时先去项目主页确认当前可用的地址。
问题四：安装时提示路径包含空格。
回头改安装目录，C:\Program Files这种路径能不用就不用。已经装完的可以重装一次，或者在settings.txt里把路径改成不含空格的，再把旧目录内容整体挪过去。
6.2 macOS 上的高频问题
问题一：装完重开终端，nvm命令找不到。
九成是 shell 配置文件没对上。echo $SHELL确认当前 shell，zsh 看~/.zshrc，bash 看~/.bash_profile。还有一种情况是配置写进去了但没生效，手动source ~/.zshrc一次看报什么错。如果 source 时报nvm.sh: No such file or directory，说明~/.nvm目录不存在，脚本可能中途失败了，重新跑一遍安装脚本。
问题二：nvm install编译原生模块失败。
这在 Apple Silicon 机器上装较老的 Node 版本时常见。原因是老版本没有预编译的 arm64 包，nvm 会退回到源码编译，而编译需要 Xcode 命令行工具。先执行xcode-select --install装好工具链，再重试。如果还是失败，装个稍新的版本通常就绕过去了，因为 Node 16 之后的版本对 arm64 的支持是完整的。
问题三：nvm use之后，新开终端又变回去了。
没设默认别名。执行nvm alias default <版本号>即可。另外检查一下.zshrc里有没有别的地方在改 PATH，比如某些工具安装时会往配置文件里追加自己的路径，把 nvm 的 source 挤到了后面，导致顺序错乱。这种情况把 nvm 的 source 段落挪到文件末尾通常能解决。
问题四：Homebrew 和脚本安装混用之后行为诡异。
which nvm看指向哪里，type nvm看是函数还是可执行文件。如果两条 source 配置同时存在，删掉其中一段，重开终端。
6.3 排查思路速查表
| 现象 | 优先检查 | 常见根因 |
|---|---|---|
| 切换后版本不变 | where node/which -a node | 旧版 Node 未卸干净，PATH 残留 |
| 命令找不到 | echo $SHELL+ 配置文件 | source 段落写错文件或未生效 |
| 安装卡住/超时 | settings.txt的 mirror 字段 | 源地址不可达 |
| 权限拒绝 | 是否管理员 / 目录属主 | 符号链接权限不足 |
| 新终端版本回退 | nvm alias default | 未设默认别名 |
| 全局包消失 | npm ls -g --depth=0 | 各版本全局目录独立，属正常行为 |
| 原生模块编译失败 | xcode-select -p | 缺少编译工具链 |
7. 几条只能靠踩坑记住的经验
配环境这件事，文档能教你的部分是有限的，剩下全靠自己撞过几次。下面几条是我在不同机器、不同团队里反复验证过的心得，写下来省得你再走一遍。
第一，永远不要在项目目录里装 nvm。有些人图省事把 nvm 装到项目文件夹下，结果提交代码时把整个~/.nvm里几百兆的 Node 运行时一起推上去了。nvm 的目录必须是全局的、独立于任何仓库的。
第二，版本号的写法要统一。nvm install 20、nvm install 20.11、nvm install 20.11.1三种写法都能用，但它们装出来的东西在不同版本上行为不完全一致——早期版本对20这种大版本号的支持不好，可能报找不到。我的习惯是永远写全三位，.nvmrc里也写全三位，避免解析歧义。
第三，切版本之前先想清楚有没有后台进程在跑。特别是 Windows，nvm use需要重建符号链接，如果此时有一个node进程正在运行（比如某个 dev server 没关），链接删不掉，命令就会失败。养成切版本前先停掉所有 dev server 的习惯。
第四，LTS 不等于「永远安全」。LTS 版本之间也会有破坏性变更，尤其是跨大版本升级时，原生模块需要重新编译、部分 API 被废弃。升级前把项目的锁文件保留一份，出问题能快速回滚。
第五，把配置过程写进团队文档。这一条听起来像废话，但真的有用。我自己维护的团队文档里有一页「环境初始化」，把 nvm 安装、镜像配置、.nvmrc约定、常见报错都写进去了，新人 onboarding 的时间从半天压缩到二十分钟。文档不用写得多漂亮，把命令和坑列清楚就够。
第六，别急着追最新版本。每次新 Node 大版本发布，总有人第一时间升上去，然后发现某个构建插件不兼容，回滚。我的做法是新版本发布后观察一两个月，等主流工具链都跟上了再切，中间用 nvm 装一个临时版本验证一下即可，反正多装一个版本的成本几乎为零。
最后分享一个我自己一直在用的小技巧：在.zshrc里加一个别名nvm-lts，内容是nvm install --lts && nvm alias default lts/*，需要换到最新 LTS 的时候一条命令搞定；Windows 上则在 PowerShell 的 profile 里加一个函数做类似的事，把nvm install、nvm use、npm ls -g三步串起来。这类小封装不起眼，但每天省下的十几秒，一年下来也是实实在在的时间。
