我刚开始自己也经历了下载很慢的情况，后来查了下原来是安装脚本默认从 GitHub 拉取文件，而 GitHub 的 release 文件在某些网络环境下确实不太稳定。标题的"nvm 淘宝镜像"容易让人误会，我以为配置一次就舒舒服服了，实际操作下来发现至少要做三处修改：nvm 安装脚本本身、npm 全局 registry、以及 node 二进制文件的下载源。这三者不配齐，前面慢完后面还会慢。

1. 先确认卡点：到底是 nvm 安装慢，还是之后下载 Node 慢？

先说清楚这个问题，因为"nvm 下载慢"这句话在不同阶段含义完全不同。我自己第一次折腾时就搞混了，走了不少弯路。

1.1 两个不同阶段的慢

第一个阶段是执行 nvm 安装脚本那一步。比如用官方那种一行命令安装，脚本会从 GitHub 上拉取 nvm 仓库的压缩包，然后解压到用户目录下。这一步慢，问题出在 GitHub 访问不稳定。第二个阶段是 nvm 安装好之后，执行nvm install 18.20.2这样的命令下载 Node 本体。这一步慢，问题出在 Node 官方源的服务器负载和网络路径上。

这两个问题表面都叫"nvm 慢"，但解决思路完全不一样。我之前遇到的情况是：安装脚本秒懂，但下载 Node 死活不动，进度条半天不走。后来和朋友交流才发现，也有人是第一步就卡住，甚至连 nvm 仓库都拉不下来。所以遇到问题先别急着配镜像，先判断自己卡在哪一步。

1.2 查看 nvm 远程仓库的命令

判断第一步是否正常，可以先执行一下 nvm 的远程仓库检查命令。这一步是通过 git 去访问 GitHub，如果这里就卡住，那大概率后面安装脚本也会卡。

nvm remote ls

这个命令实际上走的还是和 GitHub 交互的通道，正常情况下会返回一串 Node 版本号。如果你执行之后长时间没有响应或者一直报超时，那就说明 nvm 本身还没拿到 Node 版本列表，后面nvm install自然也会慢。

注意：nvm remote ls拉取的不是 Node 本体，而是版本元数据列表。就算这个命令很快，后面下载 Node 也不一定快，因为下载文件走的是另外的地址。

2. 下载慢的直接原因：不用镜像时的网络路径

这里我不说"被墙"这类词，我们就单纯从网络路径和技术实现的角度聊。默认情况下，nvm 下载 Node 时，走的地址是 Node 官方源的地址。而从国内访问这个地址，响应速度确实不稳定。

2.1 Node 下载链接的构成

了解 nvm 怎么拼下载链接很重要，因为后面配置镜像时会用到。nvm 在下载 Node 时，大致是这样的逻辑：

• 先从远程版本列表里知道你需要的版本号。
• 根据当前系统架构拼出文件名，比如node-v18.20.2-linux-x64.tar.xz。
• 然后从地址下载这个文件。

这里关键的就是这里的域名路径，也就是下载根路径。nvm 默认会用官方源的地址。你手动配置镜像时，改的也正是这个路径。

2.2 系统环境变量 NVM_NODEJS_ORG_MIRROR

nvm 本身预留了镜像配置接口，核心环境变量就是NVM_NODEJS_ORG_MIRROR。这个变量值一旦设置，nvm 下载 Node 时就会把默认的官方源替换掉，拼出新的下载链接。

我举个例子，假设你设置：

export NVM_NODEJS_ORG_MIRROR=https://mirrors.tuna.tsinghua.edu.cn/nodejs-release/

那 nvm 在下载 Node 18.20.2 时，就会尝试从清华镜像站的路径去拉文件，而不是官方源。这就是最常见的"nvm 淘宝镜像"操作。

这里要留意一点：不同 nvm 版本对变量名的兼容性不完全一样。目前主流版本认NVM_NODEJS_ORG_MIRROR，老版本可能还支持NVM_NODEJS_ORG_MIRROR但没有那么多测试。我自己用的版本，实测这个变量是生效的。

3. 配置淘宝镜像的实际操作：环境变量、安装脚本两处都要改

网上很多教程只说配置环境变量，但我用下来发现，如果 nvm 安装脚本本身也慢，还是应该一起处理。我自己保留了配好的脚本，分两部分讲清楚。

3.1 修改安装脚本拉取地址

如果你还在第一步安装 nvm 的阶段，下载脚本本身慢的话，有一个常见做法是把安装脚本里的仓库地址替换为镜像地址。具体来说，你要去拿到安装脚本，然后把脚本中的仓库地址改成 gitee 上的镜像地址。

这里我不放完整脚本代码了，因为版本更新频繁，我直接说思路：下载安装脚本后，用文本工具打开，搜索仓库地址字段，把 GitHub 地址替换为 gitee 镜像地址即可。替换后重新执行安装脚本，通常速度会有明显改善。

3.2 配置 shell 环境变量

安装好 nvm 之后，第二步就是配置环境变量。nvm 通常会在你的 shell 配置文件中写入一段初始化代码，你要在那一块代码的附近加上下面这两行：

export NVM_NODEJS_ORG_MIRROR=https://npmmirror.com/mirrors/node/ export NPM_REGISTRY=https://registry.npmmirror.com

第一行是 Node 二进制下载源，第二行是 npm 包下载源。这里我直接用的就是大家常说的"淘宝镜像"新域名。老域名现在已经不用了，注意别写错。

配置完环境变量后，要重新加载配置文件，先用echo $NVM_NODEJS_ORG_MIRROR确认变量已经生效，再继续。我自己当时第一次配置完忘了重新加载，直接执行 nvm 命令发现还是慢，白白浪费了几分钟。

3.3 Windows 用户的配置位置

以上说的是 macOS/Linux 的配置方式。Windows 用户用 nvm-windows 的话，配置方式有所不同。nvm-windows 会读取安装目录下的settings.txt文件，你需要手动编辑它。

在settings.txt中添加：

node_mirror: https://npmmirror.com/mirrors/node/ npm_mirror: https://registry.npmmirror.com

添加后保存，重启终端，再执行nvm install就会走镜像了。这里有个细节值得注意：nvm-windows 和 nvm 是两个不同项目，命令名字虽然相似，但配置文件路径完全不一样。

4. 验证配置生效：用一段实测时间来说明效果

配置完别急着装，先验证一下。空口说配置好了没用，得看实际下载速度有没有变化。

4.1 查看实际下载链接

你可以打开 nvm 的调试模式，它会打印出实际请求的完整链接。不同版本的 nvm 调试方式略有不同，常见做法是先设置环境变量再执行安装命令。我自己通常是直接看安装时的输出信息，镜.像生效时，文件下载地址会显示为镜像域名而不是官方地址。

如果你不想开调试模式，也可以直接在浏览器里访问配置好的镜像地址，看能否正常列出文件目录。能列出来说明地址可用，不能列出来说明地址拼错了或者镜像服务在维护中。

4.2 个人实测对比

我这里分享一次实际的下载对比记录，给大家一个直观感受。在未配置镜像的情况下，执行nvm install 20.11.1，下载 Node 压缩包时，速度大致是几十 KB/s 到一两百 KB/s，有时候还直接暂停。配置镜像后，同一个版本下载速度能到几 MB/s 甚至十几 MB/s，基本几秒钟就下载完。这个对比差距还是相当明显的。

下载完之后，安装过程也顺了很多。之前下载慢的时候，中途还容易断，一旦断掉 nvm 会重新尝试，体验非常差。配置好镜像之后，后续创建软链、全局安装 npm 包都走得很顺利。

5. 常见报错场景与处理：给搜索"nvm could not be found"的朋友参考

因为这个标题的搜索热词里出现了一个高频报错内容，我打算专门花点篇幅讲讲。很多朋友刚接触 nvm 时，配置环境变量或者改镜像源的过程中，可能会碰到类似报错提示。这个提示的含义是：系统找不到 nvm 相关文件。

5.1 为什么会找不到 nvm

这个报错分两种情况。一种是你真的还没安装 nvm，或者安装不完整。另一种是你安装了，但终端会话没有加载到 nvm 的初始化配置。第二种更常见，尤其是在配置 nvm 环境变量时，如果手误改错了 shell 配置文件的一行代码，会导致 nvm 命令无法识别。还有一种更隐蔽的：用户同时装了两个版本的 nvm，命令行工具可执行文件的查找路径发生冲突，导致实际执行的是另一个路径下的文件，从而报出找不到的错误。

5.2 排查的思路顺序

遇到这个报错时，我的排查顺序是固定的：

• 先检查用户目录下是否存在 nvm 目录。
• 再检查 shell 配置文件里有没有正确的初始化代码。
• 最后检查环境变量路径有没有冲突。

如果以上都正常，我会直接检查当前 shell 会话中 nvm 命令实际指向的路径，看它到底指向了哪里。之前有位同事按照网上的教程配置，结果把${NVM_DIR}拼错了，路径指向了一个不存在的目录，导致一直报错。我把他的配置改正后，问题立刻消失。

这个报错本身和淘宝镜像没有直接关系，但很多人在配置镜像的过程中会顺手改 shell 配置，容易引入新的问题。所以按上述顺序排查基本能确定问题根源。

6. 附赠的全局配置建议：npm 自身也走镜像

配置好了 nvm 的镜像，顺手把 npm 全局 registry 也配好，能省下后面很多安装第三方包的时间。这一步不属于 nvm 的"下载慢"问题，但做完前后体验差异很大。

6.1 npm registry 配置方法

直接在终端里执行：

npm config set registry https://registry.npmmirror.com

设置完之后，可以执行npm config get registry确认当前值。如果显示的是刚设置的镜像地址，就说明生效了。

需要留意的是，registry 的生效范围是当前 npm 用户级别的配置文件，不区分 Node 版本。即便你通过 nvm 来回切换 Node 版本，这个设置依然保留着。所以配置一次就够用了。

6.2 不建议全局覆盖的场景

我也看到过有人直接把镜像设置为默认全局 registry，这种做法对大多数项目没问题。但如果你的工作环境需要和企业内部私有 npm 仓库配合，全局覆盖可能会导致私包拉取失败。因为企业私有仓库的包名和作用域，和镜像站的公共包之间可能存在冲突。

这种情况建议只在具体项目目录下配置.npmrc，或者只针对某个作用域设置镜像，而不是全局覆盖。个人电脑完全用公共包的话，全局覆盖问题不大，但了解这个边界总没有坏处。

7. 从实际体验聊聊配置镜像的一些坑

最后这部分，我梳理几个自己踩过的坑和积累下来的经验，不一定在官方文档里写得很清楚，但对实际操作很有帮助。

7.1 别忽略系统架构的影响

下载 Node 时，nvm 需要识别操作系统的架构，然后拼出对应的二进制文件名。如果你在配置过程中，试图手动下载文件替换，要特别注意架构标识，执行uname -m先确认一下。我之前在一台旧电脑上装过 32 位版本的系统，就曾因为拼错架构标识，导致下载下来的是另一个架构的包，安装后直接无法运行。

7.2 配置文件的备份

修改 shell 配置文件之前，建议先备份一份。这听起来像是"废话提醒"，但在实际操作中很有用。因为 nvm 初始化代码通常不是简单一行，而是一整段条件判断，里面涉及 shell 类型判断、路径判断等逻辑，手滑删多了或者改坏了，shell 可能直接起不来。备份好了，改坏了能快速回滚，不用靠记忆盲改。

7.3 镜像源偶尔也会抽风

镜像服务整体稳定，但偶尔也会遇到文件同步延迟或者临时不可用的情况。我在一段时间内就碰到过一次，明明镜像地址配好了，但下载某个特定 Node 版本始终失败，最后切成 npm 官方源反而成功了。这种情况下不必慌，一般过一两天镜像同步完成后就恢复正常。比较稳妥的做法是，把多个镜像地址都记下来，遇到一个不行就换另一个。这里推荐一下 npmmirror 和清华镜像，两者都提供 Node 二进制文件，且稳定性都比较高。

7.4 清理 nvm 缓存的必要性

如果你在配置镜像前就尝试过下载 Node，而且下载到一半失败了，nvm 可能存在部分缓存文件。这些缓存文件有时会导致后续重试出现奇怪的错误，比如校验失败或解压异常。遇到这种情况，可以先把 nvm 安装目录下的临时缓存清理掉，再重新下载。具体路径不同版本不一样，简单起见可以直接清理 nvm 目录中你自行追加的任何未完整解压的文件，或者干脆删掉整个已下载版本的相关目录重新安装。这个处理方法我在实际中用过几次，都能快速解决问题。

经过这一整套配置，nvm 下载慢的问题基本就能解决。最后再提醒一句：镜像配置是一种借助公共基础设施的加速手段，使用之前尽量对相关服务协议和运行机制有所了解，避免在使用公共镜像时造成不必要的依赖问题。配置本身并不复杂，难的只是把各部分原理串起来。希望这篇记录能给同样遇到下载慢的朋友一点参考。