我倒觉得你无趣MacOS 上做前端或者 Node 开发，基本绕不开多版本切换这道坎。但凡你维护过三个以上的项目，就会碰到 A 项目锁在 Node 16、B 项目要用 18、C 项目已经切到 20 甚至更高的情况。这时候还在官网手动下载 pkg 安装包，来回卸载、装包，那就是纯纯给自己上强度。我自己的经验是，macOS 上装 NVM 最顺的路径就是用 Homebrew，简单、干净、卸载也方便，配合成熟度非常高的 nvm 生态，可以实现项目目录一进去就自动切到对应 Node 版本，全程不需要手动干预。这篇就完整记录一下我在这套流程里的具体操作和踩过的坑，适合刚接触 Node 版本管理、或者已经装过但想重新理一遍的开发者参考。
整篇内容包括为什么必须用版本管理、为什么选择用 Homebrew 来安装 NVM、安装过程中每一步的原理和执行后的预期结果、日常在多个 Node 版本之间切换的工作流，以及用得多了必然会遇到的各种奇奇怪怪的报错排查记录。我不敢说是标准的唯一答案，但至少是实测下来比较稳的方案。
1. 内容整体设计与思路拆解
1.1 为什么 Node 版本管理这件事绕不开
Node.js 本身迭代速度不算慢，每个大版本进来都有 breaking changes，老项目依赖的某些原生模块编译不过新版的情况太常见了。身边很多朋友最开始都觉得“我只要装一个 Node 就够了”，直到某天把项目从 16 升到 18，node-sass 直接罢工，或者某个只支持 CommonJS 的老库在 ESM-only 版本下彻底跑不起来，才开始病急乱投医。
而且每个人电脑上装 Node 的方式五花八门。有人官网下 pkg，有人装了一堆带 Node 的桌面应用，有人用完了就忘。几年下来系统里散落着多个 node 可执行文件，路径优先级一乱，命令行里 node -v 和编辑器里实际跑的版本都对不上，排查半天发现是 PATH 顺序的锅。早期我甚至见过同事直接把 npm 全局包装成 root 权限的，后面自己都清理不动。
版本管理器就是解决这类混乱局面的标准方案。NVM 不是简单的“装两个 Node 切来切去”，它真正解决的是多环境并行、全局 CLI 工具隔离、以及项目级版本锁定的问题。对个人开发者来说，核心收益就是两个：第一，想装哪版装哪版，装错了删掉也就一条命令；第二，进入某个项目目录时自动加载对应版本，不用在多个终端窗口里反复手工 nvm use。
1.2 为什么这条链路选择 Homebrew
macOS 下安装软件基本两大流派：一类走官方安装包，另一类走包管理器。Homebrew 在 macOS 开发者群体里普及率非常高，最直观的理由就三条。
第一条，卸载干净。Homebrew 安装的软件会记录文件清单，要卸载时 brew uninstall nvm 能比较完整地移除，不会像手动从 GitHub 拉脚本那样留下一堆散落在各个目录里的配置和缓存。
第二条，升级方便。NVM 这个工具本身更新并不频繁，但如果需要升级，Homebrew 一条 brew upgrade nvm 就能解决，不需要自己关注 release 动态。
第三条，依赖关系清晰。Homebrew 对 NVM 的封装会处理好安装路径、shell 配置提示等细节，安装完成后会明确告诉你要往 .zshrc 里加什么内容。对比之下，直接用 curl 拉官方安装脚本，虽然也能跑，但脚本每次输出到终端的信息更杂乱，出问题时排查路径也不如 Homebrew 的 Formula 那样透明。
有人会问：直接用 nvm 官方安装脚本不就行了吗？确实也行，官方脚本是 curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash。但这条方案依赖 GitHub 的 raw 文件下载，在部分网络环境下容易超时。而且官方脚本执行完以后，会把 nvm 的源码完整克隆到 ~/.nvm 目录，由脚本自身管理后续升级。这个思路本身没有大问题，但如果你已经日常用 Homebrew 管理开发工具，为什么不保持统一？工具链统一之后，日常维护成本是明显下降的：一条 brew update 就能盘点软件更新。
1.3 NVM 两条安装路径的差异对比
用表格梳理一下 NVM 在 macOS 上的两种主流安装路径，方便你做选择：
| 对比项 | Homebrew 安装 NVM | 官方 curl 脚本安装 |
|---|---|---|
| 安装包管理 | brew 管理，卸载/升级统一 | 独立管理，脚本自更新 |
| 文件位置 | 脚本在 /opt/homebrew/opt/nvm/ 或 /usr/local/opt/nvm/ |
~/.nvm |
| Shell 配置 | 需要手动把加载语句加入 ~/.zshrc |
脚本通常自动追加配置 |
| 网络依赖 | 依赖 Homebrew 源 | 依赖 GitHub 文件下载 |
| 卸载方式 | brew uninstall nvm + 手动清理 ~/.nvm |
手动删除 ~/.nvm 并清理配置 |
| 适合人群 | 日常使用 Homebrew 的开发者 | 不希望引入额外包管理依赖的开发者 |
我日常把所有命令行工具都交给 Homebrew，所以选择前一种方案。后续正文里的所有路径和命令，也基本以 Homebrew 方式为准，但我会把两种方案的通用注意点一起写清楚。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心细节解析与实操要点
2.1 安装前必须确认的环境检查项
不要一上来就直接 brew install nvm，先花两分钟把系统环境看清楚，后面能省掉很多定位问题的时间。
第一个要确认的是 Homebrew 本身装好了。打开终端执行 brew --version，能正常输出版本号就可以。如果没有 Homebrew，需要先安装。macOS 安装 Homebrew 理论上只要一行官方命令，但国内网络环境下 git 克隆经常卡住。常见解决办法是改用国内镜像源，先把 HOMEBREW_BREW_GIT_REMOTE 和 HOMEBREW_CORE_GIT_REMOTE 指到国内镜像，再执行官方安装脚本。这里提醒一下：不要在系统里已经存在多个相互矛盾的 Homebrew 环境时继续塞东西，之前遇到过有人装过两次 Homebrew，which brew 和 brew --prefix 指向两个不同位置，后续所有工具安装都会出问题。
第二个要确认的是处理器架构。Apple Silicon 芯片和 Intel 芯片的 Homebrew 安装路径不一样，安装 NVM 后要写入 shell 配置的路径也不同。Apple Silicon 上 Homebrew 默认装在 /opt/homebrew，Intel 上默认是 /usr/local。你可以在终端用 uname -m 确认，输出 arm64 就是