企业官网建设流程全解析

1. 项目概述：为什么Mac开发环境里Node.js需要多版本切换

打开终端输个node -v，装好的Node.js安安静静躺在那里，一切看起来岁月静好。直到某天你拉下一个老项目，package.json里写着engines: "node >= 14"，而你的本机是刚刚装好的Node 22，项目直接给你甩出一屏幕的报错。这时候才意识到，Node.js多版本切换不是折腾，是刚需。

“Node.js”这个词对前端和全栈开发者来说已经熟悉到骨子里，但真正在Mac上把它配置成一套能随用随切的开发环境，很多人是吃过亏的。官网下载的pkg一键安装，装完就锁定一个版本，想升级得重新下载，想降级得先卸载，项目一旦多了起来，这种“一条路走到黑”的装法完全撑不住场面。这篇文章就是围绕Mac开发环境中Node.js的多版本安装与切换展开的，我会把工具选型、核心操作、配置细节、踩坑实录完整梳理一遍，适合刚入门想一次性把环境搭对的开发者，也适合被多项目版本冲突折磨许久的“老油条”。

我最早在Mac上收到过最惨烈的教训是：升级系统后跑一个用了三年的Node 16项目，加密库的编译直接挂了，换了Node 18就好了。后来Compile又遇到Node 18不支持某个老依赖的语法，必须要退回14。那一次来回卸载安装浪费了半个下午，才下定决心把所有多版本管理工具研究一遍。今天这篇内容，是我在实际项目中反复验证过的完整方案，不是看了几篇文档就拼出来的理论，所有命令我都亲自跑过，所有坑我都有记录。

另外提前说明一点：本文的核心场景是macOS上的Node.js版本管理，所涉及的安装方式只使用官方网站发行版和公开的包管理工具渠道，不涉及任何非常规下载途径。搞开发环境，工具链干净、来源可查是第一原则。

2. 多版本切换的整体设计思路

2.1 这套方案要解决的核心问题

从项目维度看，Node.js多版本切换要解决的痛点非常具体：

• 不同年份的项目锁定的Node版本不同，老项目用新版本启动直接报错，新项目用旧版本又会遇到语法和性能问题。
• 全局安装的CLI工具（比如一些脚手架工具）绑定版本，切换Node版本后工具不可用。
• 某些依赖的原生模块需要在安装时针对特定Node版本编译，版本一变编译产物全部失效。
• 团队协作时，别人的环境能跑通你的环境跑不通，归根结底是Node版本一致性没有保证。

所以一套合格的多版本管理方案，至少要满足三个条件：切换及时、影响可控、操作可复现。所谓“切换及时”，就是切完版本马上生效，不用重启终端甚至不用重新登录；“影响可控”指的是切换只影响当前用户环境，不改动系统级别的全局文件；“操作可复现”则是说配置一次之后，新机器上能按照同一套流程快速恢复环境。

2.2 为什么推荐使用独立的版本管理工具

有同学可能会问：我直接去Node官网下载不同版本的pkg安装包，装新版覆盖旧版不行吗？理论上如果你只需要一个版本，这样完全可行。问题是Mac上的pkg安装器默认把Node写到/usr/local/bin或/opt/homebrew/bin，版本一多，系统只认最后装的那个，靠覆盖安装是没法实现多版本共存的。

另一种看起来可行的方法是手动下载tar.gz源码包，解压到不同目录，然后手动改PATH环境变量来切换。这条路我走过，问题在于：后续升级、删除旧版本全部需要手工处理，而且npm的全局路径也得跟着折腾，维护成本高得离谱。

最终比较靠谱的选择是用独立的版本管理工具，这类工具的思路用一个生活类比解释就是：冰箱里同时冻着好几袋肉，你想做哪道菜就解冻哪袋，冰箱本身不会把肉混在一起。版本管理工具负责下载和存储不同版本的Node.js到单独目录，切换时只是改一下当前环境的软链接指向，源文件全部保留，几分钟就能完成版本切换，不用反复卸载安装。

2.3 主流工具横向对比：n、nvm、fnm、volta

我先列一个对照表，把目前Mac生态里主流的四款Node版本管理工具放在一起比较，再讲我的选型结论。

n是最早一批的Node版本管理工具，它的设计哲学是简单直接：装完能用几条命令就完成切换。但因为它把切换逻辑建立在PATH优先级的修改上，当项目数量增多、版本切换变频繁后，容易遇到环境不干净的问题，比如某个终端会话没刷新导致指向混乱。

nvm在开发者群体里使用率最高，设计上采用软链接机制，把当前选定的Node版本目录链到nvm的工作目录，以整个PATH注入的方式保证当前Shell里执行node时命中目标版本。每个Shell会话可以独立设定版本，这点在做并发测试时优势很明显。它支持.nvmrc文件，项目里写一行版本号，进入目录后一行nvm use就完成切换。

fnm是Rust写的，安装和运行速度都飞快，而且没有Shell加载耗时，对新终端打开时的速度敏感者很友好。它支持与.nvmrc配合，也支持在指定目录下自动切换版本，不过配置项比nvm稍多一些，对新手来说有一点理解成本。

volta的思路不太一样，它用Shims机制拦截node、npm等命令的调用，工具会根据当前项目的package.json中声明的Node版本自动选择正确的运行时。好处是自动化程度最高，切目录就是自动切版本；坏处是它对工作区配置有要求，如果项目里没有版本声明，它会用默认版本兜底，对于很多“没有养成声明习惯”的团队来说，最初会有点摸不透它的脾气。

我自己的技术选型结论是：追求通用性、教程资料多、身边同事都在用的，首选nvm；在意启动速度、喜欢Rust工具链的，可以选fnm；团队项目大量使用volta统一管理，那直接上volta也省心。考虑到网上绝大多数教程和CI配置都以nvm为基准，我下面的实操部分以nvm为主线展开。但我也会把这四款工具的安装命令和基本切换方法都写出来，方便你按实际情况选。

3. 工具选型解析与安装准备

3.1 macOS上安装版本管理工具的前置要求

无论选哪款工具，Mac上装之前都要确认两件事：一是芯片架构，二是Homebrew是否可用。

芯片架构直接决定你下载的Node二进制文件是x64版本还是arm64版本。Apple Silicon的Mac（M1、M2、M3、M4系列芯片）跑的是arm64架构，Intel芯片则跑x64。查看方法很简单：终端执行uname -m，结果输出arm64就是Apple Silicon，输出x86_64就是Intel。不同的版本管理工具会自动识别架构下载对应版本，但如果你走官网手动安装包这条路，就得注意别下错。

Homebrew是Mac上最主流的软件包管理工具，绝大多数开发工具都通过它安装会省心很多。如果机器上没有装Homebrew，先到brew.sh官网按官网给的安装命令安装。安装过程比较慢，网络条件不太好的时候耗时会更长，建议耐心等它跑完，不要中途强制结束。Homebrew装好之后，用它安装版本管理工具会非常顺畅。我这里不做Homebrew安装过程的展开，因为官网安装脚本一直在更新，跟着官方文档走就是最稳的。

3.2 四款主流工具安装方式汇总

nvm安装方式（推荐方式一）：

打开终端执行官方安装脚本：

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash

如果这个方法因为网络问题一直失败，还可以走Homebrew路线安装nvm，但需要注意Homebrew版nvm在配置上有一点点区别：

brew install nvm

用Homebrew装完后，需要手动创建nvm工作目录并加Shell配置。官方脚本装好后一般会自动帮你把配置写进Shell配置文件，Homebrew版则需要手工操作。

建议装完nvm后先验证一下：

nvm --version

如果提示command not found，说明Shell配置没有生效，需要手动把下面几行加到~/.zshrc文件末尾，然后执行source ~/.zshrc：

export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"

nvm的下载脚本有很多版本，我用的是目前稳定的v0.40.3版本，你也可以到nvm的GitHub仓库里查看最新版本标签，把命令里的版本号对应替换即可。

fnm安装方式：

brew install fnm

装完后在Shell配置里加一行初始化脚本：

eval "$(fnm env)"

fnm还支持自动切换项目版本，开启方式是加个参数：

eval "$(fnm env --use-on-cd)"

volta安装方式：

curl https://get.volta.sh | bash

或者用Homebrew：

brew install volta

然后按提示执行volta setup完成Shell集成。把环境配好之后，安装指定版本Node的命令是volta install node@18。

n安装方式：

brew install n

安装指定版本用n 18.20.4，列出已装版本用n ls，切换版本直接输入n进入交互界面选择。

3.3 安装时的关键路径与Shell配置说明

以nvm为例，它的工作目录默认是~/.nvm，所有被下载的Node版本都按版本号存放在这个目录下。切换版本时，nvm会修改PATH变量，把你选定的版本目录放到最前面。这种机制的优点是把所有版本集中在一个目录里管理，不会向系统关键目录写入过多文件。

这时你可能会问：这为什么比改/usr/local/bin里的软链接更安全？因为nvm只操纵当前用户目录下的内容，不需要sudo，也不影响系统级文件。万一某天nvm出了状况，直接把~/.nvm目录删掉就能回到未安装状态，系统不会受到任何影响。

Shell配置方面，macOS从Catalina版本开始默认Shell是zsh，配置文件位置是~/.zshrc。如果你之前手动切换过bash，那么配置文件在~/.bash_profile或~/.bashrc。装工具时留意一下安装日志输出，它会告诉你往哪个文件写了配置，照着提示做就不会错。

3.4 数据库镜像源与下载速度优化

很多人在Mac上装Node相关的工具时会遇到一个烦人问题：下载慢。这里说的并不是下载安装包本身，而是两个环节：第一是nvm在从Node官网下载二进制包时；第二是npm在安装项目依赖时。

对于Node二进制包的下载，nvm用过一段时间之后会总结出一批速度更快的镜像站点。这部分操作可以根据网络情况决定是否优化，如果你感觉nvm install 18卡了很久，那么可以考虑在Shell配置里设置镜像地址，具体配置方法这里不做展开，因为不同网络环境下最优镜像不一样，而且镜像站点的可用性会波动。

对于npm依赖下载速度，终极解决方案还是使用npm官方源或各公司内部的私有源。如果你需要加速，可以在用户目录下创建.npmrc配置文件，写入：

registry=https://registry.npmjs.org

这是npm的官方源，在海外网络环境下速度很稳定。如果你用的网络环境访问官方源较慢，可以将registry值替换为你所在网络环境下实测速度更优的公共源地址。需要注意，公共镜像源的同步存在一定延迟，发布新包后偶尔会出现拉取不到最新版本的情况。

设置镜像源这件事的通用原则是：优先官方源，其次选你实际网络环境下测速最快的源，不要盲目照搬别人的配置。

4. 实操过程与核心环节实现

4.1 nvm安装与初始化完整流程

这部分是本文最核心的实操内容，我会把nvm在Mac上的完整安装、验证、配置过程逐步拆开来讲。

第一步，确认网络能正常访问GitHub。因为nvm的安装脚本托管在GitHub上，如果你的网络无法正常访问raw.githubusercontent.com，脚本是拉不下来的。社区有一种常见的规避方法是通过其他渠道获取脚本内容，但我不建议这么干，原因有两点：绕过官方渠道获取的脚本内容无法保证完整性，安全性存疑；而且安装脚本内容会随版本更新而变化，手工复制粘贴容易得到旧版内容。比较推荐的做法是：检查本地网络到GitHub的连通性，如果确实无法访问，优先考虑修正网络配置后再安装。

第二步，执行安装命令。打开终端，粘贴执行：

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash

这条命令干的事情是：下载install.sh脚本内容并直接用bash解释执行。脚本完成的工作包括：把nvm仓库克隆到~/.nvm目录，然后检查当前Shell类型，并把必要配置写入对应的配置文件。执行过程中如果出现curl: (7) Failed to connect to raw.githubusercontent.com port 443，那就是网络问题，先去解决网络连通性再说。

第三步，验证nvm安装。安装脚本跑完后，执行：

source ~/.zshrc nvm --version

正常会输出类似0.40.3这样的版本号。如果提示找不到命令，多半是配置没写对。这时直接打开~/.zshrc确认nvm配置段是否存在，没有的话手动加上。Mac的zsh配置文件中常见的坑是：配置写在了~/.zprofile而不是~/.zshrc，这样新开的终端窗口不一定会加载nvm环境。统一原则：配置写在~/.zshrc里最稳。

第四步，安装Node.js指定版本。执行：

nvm install --lts

这会安装最新的长期维护版，就是LTS版本。如果你需要特定版本，比如某个项目要求Node 18：

nvm install 18.20.4

nvm会自动从Node官网下载对应v18.20.4的二进制包，下载完成后自动设置为当前版本。安装过程中会顺带安装对应版本的npm，不需要额外操作。

第五步，设置默认版本。如果你希望以后打开新终端默认使用某个版本：

nvm alias default 18.20.4

设置之后再验证一下：

node -v npm -v

输出的版本号如果和安装的一致，说明环境已经通了。

4.2 多版本安装与切换的核心命令

多版本管理工具的价值在于“多版本”三个字，所以在装好第一个版本之后，再来一个版本才算真正发挥工具的作用。

继续安装另一个版本，比如Node 20的LTS版本：

nvm install 20

此时机器上有两个Node版本。用以下命令查看全部已安装版本：

nvm ls

输出结果里会列出系统当前使用的版本、默认版本以及所有已装版本，当前使用的版本前会带一个箭头标记。切换到某个版本的命令很简单：

nvm use 18.20.4

执行完再跑node -v确认是否切换成功。这个切换是当前Shell会话级别的，也就是说：你在终端窗口A切换到Node 18，不会影响终端窗口B里的Node版本。如果希望全局生效，就用nvm alias default指定默认版本载入新终端。

对项目场景来说，最实用的操作是在项目根目录创建.nvmrc文件：

echo "18.20.4" > .nvmrc

之后进入这个项目时执行：

nvm use

nvm会读取.nvmrc文件里的版本号自动切换。如果当前机器没有安装该版本，nvm会给出提示，你可以执行nvm install配合.nvmrc完成安装。这个文件的版本号格式可以稍微灵活，比如写18或lts/iron都行，具体看项目约定。

npm全局包的管理有个被很多人忽略的细节：nvm切换Node版本后，全局安装的npm包不会自动同步过来。比如你在Node 18下全局装了yarn，切换到Node 20后想用yarn会提示找不到命令。解决办法有两个：一个是在新版本下重新全局安装一遍需要的工具，另一个是记住各版本下工具的差异，在项目里尽量用npx按需调用，减少对全局包的依赖。我的个人习惯是全局只保留少数几个工具，项目依赖一律走package.json。

4.3 卸载旧版本与清理残留

多版本管理不是只会装、会切就够了，卸载同样重要。时间一长，旧版本越积越多，磁盘空间被无意义占用，就该清理了。

卸载指定版本：

nvm uninstall 14.17.0

执行之后，该版本的Node和npm都会从~/.nvm目录下移除。如果该版本当前正在使用中，nvm会提示你先切换到其他版本再执行卸载。

清理残留这块有个容易踩的坑：有些同学早期用官网pkg方式安装过Node，然后又装了nvm。这时候即使nvm切换了版本，系统里可能还存在一份旧版的安装残留，which node的指向会比较混乱。我遇到过一次：终端里明明执行了nvm use 18，但node -v仍然显示16，排查了半天发现是Shell配置里PATH顺序的问题。解决办法是把Shell配置文件里所有手动添加的Node路径全部删掉，让nvm完全接管Node的PATH管理。

4.4 fnm与volta的快速上手对比实操

为了让你有更完整的选型参考，我把fnm和volta的实际操作流程也走一遍，和nvm做个直观对比。

fnm实操：

安装命令brew install fnm，配置初始化脚本：

eval "$(fnm env --use-on-cd)"

安装两个版本：

fnm install 18.20.4 fnm install 20.11.0

查看已装版本：

fnm list

切换版本：

fnm use 20.11.0

设置默认版本：

fnm default 20.11.0

fnm的--use-on-cd模式会在shell识别到目录包含.nvmrc或.node-version文件时自动切换版本，比nvm的“手动执行nvm use”更进一步。实际体验下来，fnm的切换速度确实比nvm快，因为它是Rust编译的二进制，不用每次启动时跑一遍Shell脚本。但fnm的配置项更多，新手很可能在配置阶段就失去耐心。

volta实操：

安装命令curl https://get.volta.sh | bash，然后执行volta setup完成环境初始化。用volta安装并固定Node版本：

volta install node@18.20.4

volta最大的特性是会把Node版本“钉”在项目的package.json里。比如你在项目A里执行过volta install node@18，再执行volta pin node@18，那么项目的package.json中会记录Volta的版本配置，团队成员拉下项目后只要也装volta，node命令就会自动使用同一版本。这种“项目级自动版本锁定”的体验是最好的，但前提是整个团队统一用volta，否则版本一致性就无从谈起。

4.5 基于项目需求的Node版本选择策略

选定哪个Node版本，不是越新越好。这里给一个相对保守的选择逻辑：

• 如果是2024到2026年之间新启动的项目，Node 20 LTS或Node 22 LTS是稳妥选择，生态兼容性好，性能有明显提升。
• 如果是需要兼容企业级老系统、老依赖库的项目，Node 16或Node 18是常见选择，但要注意Node 16已经过了EOL时间，安全更新已经停止，生产环境不建议再用。
• 如果项目里用到了较新的语言特性（比如较新版的TypeScript、较新语法），那直接上当前最新的LTS版本就好。
• 如果只是本地做工具脚本，选默认LTS版本就够了，不需要折腾多个版本。

查看一个Node版本的维护状态，最直接的方法是访问Node官网的发布信息页，它能清晰看到每个大版本的维护状态和EOL时间。

那么多版本切换这句话的本质，是让你“该新则新、该稳则稳”，而不是为了切而切。版本选型的核心依据始终是项目依赖的兼容性和你确定的部署环境的Node版本。

5. 常见问题与排查技巧实录

5.1 Shell配置不生效与PATH混乱问题

症状：执行nvm -v提示command not found，或者新开一个终端窗口后nvm命令就消失了，需要手动执行source ~/.zshrc才能恢复。

排查步骤：

ls -la ~/.nvm

确认nvm目录是否存在。如果目录不存在，说明之前安装没有完成；如果目录存在，问题出在Shell配置加载上。用cat ~/.zshrc查看文件末尾，确认nvm配置段是否完整。有次我帮同事排查，发现他的nvm配置被写进了~/.bash_profile，但他终端用的是zsh，当然不会加载那部分配置。

PATH混乱这个问题更隐蔽：node -v输出的版本和nvm current输出的版本不一致。通常是因为手动安装过官网pkg包，导致/usr/local/bin/node这个路径在PATH里比nvm管理的路径更靠前。

解决办法：检查Shell配置里有没有手动设置的Node相关路径，比如export PATH="/usr/local/bin:$PATH"，有的话删掉，让nvm配置保持在配置文件的最后面。再执行which -a node查看所有被找到的node路径，历史残留路径全部清理干净。

5.2 系统架构不匹配导致的安装失败

症状：执行nvm install 18后提示下载成功，但运行node -v时报Bad CPU type in executable。

原因：nvm从Node官网下载二进制包时识别架构出错，可能下载了x64版到arm64的Mac上。

处理方式：

nvm uninstall 18 arch -arm64 zsh nvm install 18

在Apple Silicon的Mac上，用arch命令强制以arm64模式重新开一个Shell再执行安装。还有一种可能是手动指定架构：

NVM_NODEJS_ORG_MIRROR=https://nodejs.org/dist nvm install 18 --arch=arm64

5.3 权限问题与文件锁占用

症状：执行nvm install时提示Permission denied，或者运行时提示EACCES: permission denied。

如果你安装Node时用到了sudo提权，那npm全局目录的归属就会出现问题。解决方法是把npm全局目录的所有权归还给当前用户，在~/.npmrc中配置：

prefix=${HOME}/.npm-global

同时确保npm全局包的缓存目录也对当前用户可写。经常在npm install过程中遇到无法删除临时文件的报错，通常是因为上次安装被强制中断，残留的临时文件锁住了目录，清理一下npm缓存：

npm cache verify npm cache clean --force

5.4 下载速度慢与超时问题

现象：执行nvm install 18时卡在Downloading阶段，很长时间没有响应，最后超时失败。

这类问题基本上都是网络原因。Node二进制包体积大概在20-40MB，在正常网络下不会卡太久。如果你网络环境特殊，可以考虑配置镜像地址来加速下载。在~/.zshrc中，将nvm的下载地址指向Node官网的官方分发目录或者你实测可用的镜像目录：

export NVM_NODEJS_ORG_MIRROR=https://nodejs.org/dist

请注意：设置镜像地址本质上只改变下载路径，不影响版本内容的一致性。关键还是去测试你所处网络环境里哪个地址能达到正常速度，然后写入配置。

npm层面的下载速度慢，常规手段是切换registry源，前面提到过在~/.npmrc里配置。这里再补充一个观点：如果你经常遇到npm下载一半报错，检查一下是否设置了过于激进的前缀或代理变量，比如HTTP_PROXY、HTTPS_PROXY这类环境变量对下载链路影响很大，有时候清空反而能解决。

5.5 卸载残留与清理完整指南

有时候你会遇到“明明卸了Node，运行node -v还有输出”的情况。这说明还有残留版本在PATH里。

清理步骤：

which -a node which -a npm

把列出的所有路径逐一检查，凡是不在nvm目录下的Node相关可执行文件，基本都是历史安装残留。手动删除时优先删除用户目录下的安装残留文件，系统目录下的残留如果确认是早期pkg安装产生的，也可以一并清理。清理完成后重新打开终端执行node -v，如果提示command not found，说明已经清干净。

如果你彻底不想用nvm了，卸载方式也简单：删除~/.nvm目录，再删掉Shell配置里的nvm配置段。

5.6 版本切换后全局包失效的处理方法

切换版本后，全局工具命令找不到，前面已经提到了原因：nvm按版本隔离全局包。如果实在需要某个全局工具在所有版本下可用，有两个思路：

一是每个版本都装一遍。维护成本高，但不折腾。

二是用npx替代全局安装。绝大多数CLI工具都支持npx方式调用，比如npx create-react-app my-app，它会临时下载并执行，不会污染全局环境。这个方式也是我在多个团队里推行的习惯，好处是项目依赖关系更清晰，坏处是首次执行会稍慢一点。

5.7 使用过程中值得养成的几个习惯

多版本切换这件事，配置一次之后就是细水长流。几个实际使用中总结的习惯供参考：

• 新建项目时先创建.nvmrc文件，哪怕现在就一个版本，也要养成声明版本的习惯。这个文件对后续接手项目的同事价值巨大。
• 不要频繁切换Node版本来排查问题，先用npm ls确认依赖树中是否存在需要重新编译的原生模块，再决定要不要切版本。
• 不要用sudo执行npm install -g。npm的全局安装目录权限问题，用修改prefix配置解决，而不是提权。
• 在Shell里使用nvm current快速查看当前版本，别总是敲node -v，nvm current会告诉你当前版本和默认版本的差异，排查环境问题时更快。

6. 实操经验总结与后续扩展方向

整套方案实践下来，我个人最大的体会是：Node.js多版本切换选哪个工具不重要，重要的是建立“版本与项目绑定”的意识。工具永远只是手段，让你在项目切换、人员协作、依赖兼容这些问题面前不再手足无措，那这套环境搭建就值回票价了。

有一件事值得单独拿出来说：版本管理工具装好之后，记得把“版本声明”变成一种团队规范。.nvmrc文件、package.json里的engines字段、以及CI配置文件里的Node版本设置，三者联动，项目的可复现性才会有质的提升。我在实操中发现，很多项目部署到服务器就挂，排查半天发现本机和CI上版本不一致，问题不在工具，在于没有统一入口去声明版本。

如果你打算在Mac上一次性把开发环境配到位，我的建议是按这个顺序走：先装Homebrew，再通过Homebrew装nvm，用nvm装LTS版本Node，最后把npm的源配置好。整个过程熟练的话十分钟之内搞定，这个基础环境后面无论你做前端、全栈还是Node服务端开发，都不用再回头操心版本问题。

针对多版本管理工具，从nvm起步，用熟了之后如果觉得每次Shell加载有点慢，再试试fnm；如果团队协作越来越密切，可以研究Volta的项目级自动切换机制。工具切换的成本很低，不必有“选错了就完了”的顾虑。

最后再分享一个小技巧：nvm安装完版本之后，自动设置的默认版本可能不是你想要的。如果你想做一次彻底的默认版本重置，先清空默认别名再设置新的：

nvm unalias default nvm alias default 18.20.4

相比直接nvm alias default覆盖，先unalias能避免一些边界情况下默认版本指向异常的问题。这种小细节，在“某天新开终端突然发现node版本不对”的时候，能帮你省下不少排查时间。

环境的稳定性和可复现性，本质上是把习惯做对。Node.js版本切换工具只是撬点，希望这篇内容能帮你在Mac上一步到位，把环境问题变成过去式。