企业官网建设流程全解析

Node.js 版本太多不知道当前用哪个，又不敢随便升级怕项目跑不起来？这篇文章整理了查看本机 Node 版本和切换版本的全套方法，包含 NVM 的安装、常用命令、实战切换流程和常见报错排查，帮你在多版本环境里来去自如。

1. 为什么我们需要管好 Node 版本

做前端或 Node 开发的人，大概率都遇到过这种场景：电脑上装了一个 Node，跑老项目的时候报错说某个 API 不支持，查了一下发现是 Node 版本太新了，有些旧语法被废弃了。或者反过来，新项目要求 Node 18，结果自己机器上还是 12，装依赖直接一堆警告。

Node 版本管理不是什么高深的东西，但没弄好的话非常折腾。我之前见过不少同事，为了跑不同的项目，直接在官网下载不同的安装包来回覆盖装，装到后面自己都记不清系统里到底是哪个版本，node -v输出的结果完全取决于最后一次装的是哪个。这样做的风险很大，因为你没法保证下一次重新装系统或者换电脑的时候，还能原样复现这套环境。

用一款版本管理工具（比如 NVM 或者 n）就能解决这个问题。核心思路很简单：不把 Node 固定在某个全局路径里，而是通过工具在多个已安装版本之间做切换，切换只对当前 shell 生效。这样你就可以同时保留 Node 14、16、18、20 甚至更高版本，哪个项目需要哪个版本，随时切过去。

这篇文章主要面向的是那些已经在用 Node、但还没用版本管理工具的人。如果你已经装了 NVM 但平时只用一个版本，也可以看看后面的切换原理和排查方案，能帮你少踩不少坑。

2. 先搞清楚自己电脑上装了几个 Node

2.1 最简单的检查方法

在任何终端里，直接输入一个有且只有一行的小命令：

node -v

如果正常运行，会输出类似v18.17.0这样的版本号。这条命令能告诉你当前 shell 的 PATH 中，排在最前面的那个 Node 是什么版本。

但这只代表了“你正在用的”那一个版本。你电脑里可能藏着其他版本，只是没生效。想找出所有版本的话，要分情况看。

2.2 用 which 查看当前 Node 的实际路径

which node

Linux 和 macOS 会输出一个路径，比如/usr/local/bin/node或者/Users/你的用户名/.nvm/versions/node/v16.20.2/bin/node。Windows 上可以用where.exe node。

看路径就能猜个大概：

• 如果路径里带.nvm，说明当前版本是由 NVM 管理的。
• 如果路径是/usr/local/bin/node，那可能是通过官方安装包或者 Homebrew 装的。
• 如果路径是C:\Program Files\nodejs\node.exe，那就是 Windows 安装包的标准目录。

2.3 检查安装包管理器记录了哪些版本

如果你用的包管理器是 Homebrew，可以用brew list | grep node来看装了什么node相关的 formula。如果用的是 nvm，直接看这个目录：

ls ~/.nvm/versions/node

我见过不少人一直以为电脑里只有 18，结果一列这个目录，发现十几二十个版本整整齐齐躺在那里，全是以前装完忘了切回来的。

2.4 一屏看全所有 Node 版本

如果当前环境是用 NVM 管的，日常最常用的是这个命令：

nvm ls

它会输出当前已安装的所有版本。当前正在使用的版本前面会带一个绿色箭头（某些版本里是->符号），系统自带的版本也可能会单列出来显示。

nvm ls-remote

这条会列出所有远程可安装的版本，数量非常多。想看 LTS 版本，可以使用：

nvm ls-remote --lts

只有先搞清楚自己手上有多少版本、每个版本对应哪个项目，后面的替换版本操作才有意义。连自己有什么都不知道就开始乱切换，后期排查问题时只会更乱。

3. 主流的 Node 版本管理工具对比

要“替换” Node 版本，其实有几种做法。先看对比，再选自己用得顺手的。

日常选择的话，我建议 macOS/Linux 直接用 NVM，Windows 用 nvm-windows 或者 fnm。不要图省事，直接在官网下载安装包覆盖安装，因为那样你永远无法做到多版本共存和随时回退。

4. 全新安装 NVM 的完整流程

如果你还没装任何版本管理工具，可以参考这一套流程。我以 macOS 和 Linux 为例，Windows 用户可以直接跳到 4.4。

4.1 检查本机是否已有 NVM

先跑一遍：

nvm --version

如果提示command not found，说明还没装。注意 macOS 上即便你brew install nvm了，也默认不会加载它的 shell 脚本，需要自己配置，这也是很多人装完发现nvm用不了的原因。

4.2 正式安装 NVM

主流方式是使用 NVM 官方安装脚本：

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

如果curl拉不下来或网速很慢，可以直接去仓库下载install.sh到本地后执行：

bash install.sh

安装过程会在你的用户目录下创建~/.nvm，并在~/.bashrc、~/.zshrc或~/.profile中追加几行配置，内容大致是：

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

配置追加完成后，默认情况下需要重新打开终端或者手动执行一次：

source ~/.zshrc

如果你用的是 zsh，别忘了~/.zshrc才是实际生效的文件。

4.3 验证 NVM 是否装好

nvm --version

只要输出版本号，就算安装成功。之后再装 Node 就千万不要再用官方安装包了，所有版本统一交给 NVM 管。

4.4 Windows 用户的 nvm-windows 安装

Windows 没有 sh 环境，直接去 nvm-windows 的 GitHub 仓库下载nvm-setup.zip，解压后双击安装即可。安装时它会建议你选择 Node 的 symlink 目录，一般保持默认C:\Program Files\nodejs就行。

装好之后，用管理员身份打开命令行，执行：

nvm version

能输出版本号就说明安装成功。注意 Windows 下不要混着用 nvm 官方脚本，那是给 mac/Linux 准备的，硬套会用不了。

4.5 安装自己需要的第一个 Node 版本

nvm install 20.11.1

指定完整版本号最稳妥。如果想装某个大版本的最新版，可以直接：

nvm install 20

等待它下载解压完成后，再把它设为默认：

nvm alias default 20.11.1

这样每次打开新的终端，默认就会加载 V20.11.1。

5. 查看现有版本并切换：核心实操环节

假设你已经用 NVM 装了几个版本，接下来看怎么切换。

5.1 列举本地版本

nvm ls

输出的内容很像这样：

v16.20.2 v18.19.0 -> v20.11.1

那个->指向的就是当前 shell 正在使用的版本。

5.2 切换到另一个版本

nvm use 18.19.0

执行完，后面的node -v就会显示v18.19.0。这个切换只对当前终端窗口有效，新开一个终端，会退回默认版本。

5.3 永久切换到某个版本

如果你确认某个项目就是要长期用 V16，可以：

nvm alias default 16.20.2

这样新开的终端默认就是 V16。

5.4 用项目级配置文件锁版本

比起靠脑子记哪个项目用哪个版本，更推荐每到一个项目根目录，放一个.nvmrc文件，内容就一行：

18.19.0

也可以在文件里写特殊别名，比如lts/hydrogen。进入项目目录后执行：

nvm use

NVM 会读取.nvmrc里的版本号并自动切换。某些较新版本的 NVM 甚至支持检测到.nvmrc时自动切换，但我建议习惯性手动敲一下，以免环境不识别导致误用错误版本。

5.5 用 nvm exec 在指定版本下执行命令

如果你想在特定版本下运行一条命令，但不想切换当前 shell 的版本，可以：

nvm exec 18.19.0 node app.js

这会只在那一条命令执行时使用 V18.19.0，非常适合临时跑脚本验证兼容性。

6. 如何安全卸载不需要的版本

有时候版本装多了，看到nvm ls输出一大串也会觉得乱。卸载有风险，先想清楚再动。

6.1 先确认当前没在用要卸的版本

nvm ls

如果要卸载的版本恰好是当前正在使用的版本，卸载行为会把它直接删掉，当前 shell 的 node 就失效了。建议先切走：

nvm use 20.11.1

6.2 执行卸载

nvm uninstall 16.20.2

卸载之后，nvm ls就不会再列它了。如果你之前设过alias default 16.20.2，卸载完还要及时更新默认别名，否则新终端打开时会提示找不到对应版本。

6.3 确认全局依赖是否需要保留

每个版本的 Node 都有自己独立的全局包目录，卸载版本不会备份这些全局包。如果真的在某个旧版本下全局装了某些工具，先考虑清楚后续在哪个版本用。

7. 切换 Node 版本时最容易踩的坑

这个部分几乎每一个做 Node 开发的人都会遇到，而且这些问题查资料经常查不到准确答案，我把我实际踩过的都说一遍。

7.1 切换后 node -v 没变化

大部分情况是 shell 配置没重新加载。先执行：

source ~/.zshrc source ~/.bashrc

还不行，就检查 PATH 里是不是有别的路径排在了 NVM 的路径前面。比如你之前手动装过/usr/local/bin/node，那么可能这条路径先被找到。这时改一下 PATH 顺序，让$NVM_DIR/versions/node/当前版本/bin排在前面。

关闭当前终端，新开一个窗口，再执行node -v看结果。如果还不行，彻底重启一次终端。

7.2 提示N/A: version "xxx -> N/A" is not yet installed

通常是.nvmrc里写的版本号，或者某个别名对应不上。检查：

cat .nvmrc

确认文件里写的是完整版本号，比如18.19.0，不要写lts以外的特殊字符。如果是自己设的别名，先跑nvm alias看看别名定义。

7.3 npm 的版本跟 node 不同步

有些版本切换会发现node -v是要求的版本，但npm -v却不是预期版本。这是因为当前版本的 Node 全局 npm 被覆盖或者使用了不匹配的版本。解决办法：

nvm use 18.19.0 npm install -g npm@10

或者直接删除当前版本的全局 npm 覆盖，再用对应 Node 版本内置的 npm：

nvm uninstall 18.19.0 nvm install 18.19.0

7.4 切换后全局包找不到了

这是很多新手迷惑的地方。Node 的全局包和 Node 版本强绑定，意味着你在 V18 下npm install -g的包，切到 V16 后就没有了。这不是版本管理工具的问题，而是它的设计如此。

常用解法：

• 切换到旧版本后，重新安装需要的全局包。
• 用 npx 代替全局安装。
• 有大量全局包需要统一维护时，考虑用 pnpm 或 yarn 的全局管理机制。

7.5 Windows 下提示无法加载文件，因为在此系统上禁止运行脚本

PowerShell 默认执行策略限制明显。管理员身份打开 PowerShell，执行：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

再重新试nvm version。这个操作只在当前用户生效，不会影响系统的其他安全策略。

7.6 切换后 npm install 出现一堆 peerDependencies 报错

多数情况下是使用的版本和项目锁定的版本不一致。确认锁定文件：

• 项目有package-lock.json，就严格用锁定文件的版本。
• 有engines字段的，先看一眼 npm 版本是否满足要求。

npm config get registry

如果某些依赖源是特殊私服，还要注意版本解析规则可能和官方源不一致。

8. 实操记录：一次从 V18 切换到 V20 并跑通项目

光讲理论不够，分享一次实际切版本的演示，方便你完整建立操作链路感。

8.1 场景还原

某天接到一个任务，要把一个老项目从 Node 18 升级到 Node 20 试试兼容性。项目依赖几十个，包含一些原生编译的模块，直接跨版本跑可能会报编译错误。

先看当前版本和已安装列表：

node -v nvm ls

当前确实是 V18.19.0，而且 V20.11.1 也已经装过了。

8.2 切换版本并验证

nvm use 20.11.1 node -v npm -v

node -v已经输出v20.11.1。npm -v输出 10.x，符合 Node 20 的配套。此时再检查全局工具是否可用：

which yarn

如果之前是用 npm 全局装的 yarn，切换版本后很可能找不到了。需要重新执行一次安装，这是预期行为，不用慌。

8.3 清理旧依赖并重装

项目根目录下执行：

rm -rf node_modules rm -rf package-lock.json npm install

如果没有生成 lock 文件或者仓库不接受改 lock，可以先只清node_modules，再npm install。这一步的目的不是清理，而是让项目在全新的版本环境下重新解析依赖树，避免旧版本解析出来的二进制产物残留。

8.4 跑测试和构建

npm run test npm run build

如果遇到 node-sass 或者 node-gyp 相关的报错，大概率是要重建原生模块。典型命令：

npm rebuild

还不行就把涉及原生模块的依赖重装一次。实践下来，大部分升级兼容性问题到这一步都能解决。

8.5 切换回旧版本

确认 V20 下项目没问题后，再切回 V18，确保日常开发环境不变：

nvm use 18.19.0

然后果断重跑一遍测试，确认团队里其他人还在用 V18 时，改动不会出问题。

这一整套流程做下来，比直接覆盖安装 Node 版本要安全太多了。你永远有一个可以随时回退的环境。

9. 如果不用 NVM，还有哪些备选方案

并不是所有人都想用 NVM。如果你的使用习惯比较特殊，可以考虑其他方案，我这里简单说一下。

9.1 用 Docker 管理 Node 环境

如果你的项目跑在容器里，那版本管理可以直接交给镜像标签。比如：

docker run --rm -it node:20.11.1 bash

这样你本机甚至不需要装 Node，也完全不会被版本问题困扰。缺点是即使是最好的容器方案，也有调试体验上的隔阂，比如断点调试、源文件映射等需要额外配置。

9.2 用 fnm 作为 NVM 的替代

fnm 的安装命令很简洁（需要已经装了 cargo 或者直接用安装脚本），支持.node-version和.nvmrc。执行速度上比 NVM 快不少。日常命令的体感差异不大：

fnm install 20.11.1 fnm use 20.11.1 fnm ls

如果你就是觉得 NVM 那句nvm use加载太慢，或者不喜欢 shell 函数带来的延迟，可以试试 fnm。

9.3 团队强制监管版本时，用 volta

Volta 的做法是把版本锁定到项目，它会在package.json中写入volta字段，团队成员同用一个锁定的 Node 版本。优点是进项目目录后自动切，基本不需要手动操作。缺点是项目里如果没有提前配置好，也会有初始化成本。

10. 最终的一点实际经验

根据我长期使用的经验，这套技术栈里最容易破坏环境的不是版本管理工具本身，而是“偶尔用官方安装包装一次新版本”。只要我不小心用了官方安装包，PATH 里的路径优先级就会混乱，导致nvm use之后看起来生效了，但新开一个终端又变回去。后来我给自己定了一条很简单的规矩：所有 Node 一律 NVM 管，操作系统全局路径中不允许出现独立的 Node。

另外想说两个小细节：

第一，NVM 的alias不只是能设default。你可以给某个版本设一个项目专用别名：

nvm alias myproj 16.20.2

然后在项目里用nvm use myproj，比每一次都敲完整版本号更清晰。

第二，CI 环境下很多团队使用nvm install加nvm use，但因为 CI 环境的 shell 环境和本机不完全一致，建议在里面加上具体的版本号，千万别只写nvm install && nvm use，否则依赖环境变量的默认值容易出现不可复现问题。

附带再提一嘴，版本替换前，最好把依赖锁文件提交到 Git。锁文件的意义不只是让人知道依赖版本范围，也是让工程切换 Node 版本后更容易回溯问题。团队里一旦有人升过 Node 版本，锁文件里的依赖解析痕迹就是排查问题的最重要线索。

Node 版本管理本质不是什么高深技巧，但它直接影响日常开发效率和项目稳定性。把这一套流程练熟了，遇到任何版本兼容问题都会有底气。我自己的习惯是每个 Laravel 级别的大项目进去之前，先cat .nvmrc，再看 package.json 里的 engines 字段，两秒钟决定切换哪个版本，省下来的时间全部花在实实在在的开发上。