Node.js 开发环境安装与 npm/pnpm 国内镜像配置（Windows / macOS / Linux）

适用人群：第一次搭建 Node.js 环境的前端、Node.js 开发者，以及遇到依赖下载慢、node 命令找不到、npm/pnpm 源混乱等问题的读者。

本文验证基线：2026 年 9 月 2 日；Node.js v24.20.0 LTS、npm 11、pnpm 11。版本号会继续更新，实际安装时请以 Node.js 官网标注的 LTS 版本为准。

很多人第一次配置 Node.js，都会觉得这件事应该很简单：下载安装包，一路点"下一步"，然后执行 npm install。

真正开始以后，问题却一个接一个：

• node -v 能执行，npm -v 却报错；
• 在系统终端里能运行 Node.js，到了 VS Code 终端里却提示"找不到命令"；
• npm install 长时间卡在某个依赖上；
• npm 已经换成国内镜像，pnpm 仍然访问另外一个地址；
• 电脑里同时存在两三套 Node.js，终端实际调用的不是刚安装的版本；
• 为了解决证书错误，照着旧教程执行了 strict-ssl=false，下载是恢复了，安全校验也一起被关掉了。

这些问题看起来各不相同，实际上集中在四件事上：版本、安装路径、环境变量和 Registry 配置。

本文不只给出几条"复制就能用"的命令，还会把每条命令改了什么、如何检查、如何恢复讲清楚。最终我们要得到的是一套可验证、可切换、出问题时也能回退的 Node.js 开发环境。

---

一、先把 Node.js、npm、npx 和 pnpm 的关系说清楚

在开始安装之前，先不要急着改配置。

工具	作用	是否随 Node.js 安装	本文中的定位
Node.js	在浏览器之外运行 JavaScript 的运行时	---	整套环境的基础
npm	安装、升级、发布 JavaScript 包	是	默认包管理器
npx	临时执行 npm 包提供的命令	通常随 npm 提供	用于执行一次性工具
pnpm	使用内容寻址存储和链接机制管理依赖	否	更节省磁盘，适合多项目和 Monorepo
Registry	保存包元数据和包文件的仓库服务	---	npm/pnpm 下载依赖时访问的服务

这里最容易混淆的是最后一项。

把 npm 或 pnpm 的 Registry 改成国内镜像，只会改变依赖包从哪里查询和下载。它不会自动替你安装 Node.js，也不会改变 Node.js 本身的下载地址。

可以把它理解为：

Node.js：运行 JavaScript 的发动机
npm/pnpm：负责搬运和管理依赖的工具
Registry：依赖包所在的仓库

所以，正确顺序应该是：

1. 安装受支持的 Node.js；
2. 验证 node 和 npm 命令；
3. 根据需要配置 Registry；
4. 安装并验证 pnpm；
5. 创建一个最小项目完成闭环测试。

---

二、应该安装哪个 Node.js 版本？

Node.js 官网通常会同时展示 LTS 和 Current 两条版本线。

• LTS（Long-Term Support）：长期支持版本，适合日常开发、教学和生产项目；
• Current：包含较新的运行时特性，适合提前测试新能力；
• EOL（End of Life）：已经结束官方支持，不应再用于新项目。

截至 2026 年 9 月 2 日，Node.js 官网显示：

版本线	状态	是否建议用于新环境
Node.js 24	LTS	推荐
Node.js 22	LTS	老项目兼容时可以使用
Node.js 26	Current	适合测试，不作为本文默认选择
Node.js 20 及更早版本	已进入或已经处于 EOL	不建议用于新项目

本文以 Node.js 24 LTS 为例。以后阅读本文时，如果 24 已不再是受支持版本，请直接选择官网当时标注的最新 LTS，不要机械照抄旧版本号。

2.1 x64 和 ARM64 怎么选？

设备	一般选择
常见 Intel/AMD Windows 电脑	x64
Windows on ARM 设备	ARM64
Apple Silicon Mac（M1、M2、M3、M4 等）	ARM64
Intel Mac	x64
Linux uname -m 显示 x86_64	x64
Linux uname -m 显示 aarch64 或 arm64	ARM64

架构选错不一定会立刻报错。有些系统可以通过兼容层运行，但原生模块安装、性能和调试都可能出现额外问题。能装原生架构，就不要依赖兼容层。

2.2 安装前先检查电脑里有没有旧版本

Windows PowerShell：

node -v
npm -v
where.exe node
where.exe npm
Get-Command -All node -ErrorAction SilentlyContinue

macOS / Linux：

node -v
npm -v
which -a node
which -a npm

如果输出了多个路径，不要直接删除其中某个目录。先确认它来自官方安装包、Homebrew、系统软件仓库还是版本管理器，再通过原来的安装方式卸载。

尤其不要同时混用下面几种方式：

• 官方安装包；
• Homebrew、apt、dnf 等系统包管理器；
• nvm、fnm、Volta 等 Node.js 版本管理器；
• 手动解压的二进制文件。

它们都能工作，但混在一起以后，PATH 中排在前面的版本会抢先被执行。你以为自己升级了，终端可能还在调用旧版本。

---

三、Windows 安装 Node.js

对于第一次搭建环境的 Windows 用户，建议优先使用 Node.js 官网提供的 .msi 安装包。它会自动完成文件安装和 PATH 配置，出问题时也能从"已安装的应用"里修复或卸载。

3.1 下载 LTS 安装包

打开 Node.js 官方下载页：

https://nodejs.org/en/download

确认页面上选中的是 LTS，再根据电脑架构下载：

• Intel/AMD 电脑：Windows x64 Installer；
• Windows on ARM：Windows ARM64 Installer。

不要从不明软件下载站获取"绿色版"或二次封装安装包。开发环境会执行来自项目的脚本，运行时本身应尽量使用可信来源。

3.2 完成安装

双击 .msi 文件后，按照向导安装。一般保留默认选项即可，重点确认以下组件没有被取消：

• Node.js runtime；
• npm package manager；
• Add to PATH。

安装向导可能提供"自动安装原生模块编译工具"的选项。它会额外安装 Python、Visual Studio Build Tools 等较大的组件。如果当前只是学习 JavaScript、使用 Vite 或普通前端框架，可以先不勾选；以后遇到必须本地编译的原生依赖，再按项目要求安装对应构建工具。

安装完成后，把已经打开的 PowerShell、CMD 和 VS Code 全部关闭，再重新打开。旧终端进程不会自动刷新 PATH。

3.3 验证 Windows 环境

重新打开 PowerShell，依次执行：

node -v
npm -v
npx -v
where.exe node
where.exe npm
node -p "process.platform + ' ' + process.arch"

正常情况下，最后一条应输出类似：

win32 x64

如果 node -v 有结果，而 npm -v 提示脚本不能运行，可以先尝试：

npm.cmd -v

这通常不是 npm 没装好，而是 PowerShell 的脚本执行策略阻止了 npm.ps1。不要直接把策略改成 Unrestricted。个人电脑可以在理解影响后，将当前用户策略设置为：

Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

公司设备应先遵守组织安全策略；不允许修改时，使用 npm.cmd、pnpm.cmd，或者改用 CMD 终端。

---

四、macOS 安装 Node.js

macOS 上既可以使用官方 .pkg，也可以使用 Homebrew 或版本管理器。本文选择官方安装包，原因很简单：步骤明确，适合第一次安装，也不会把 Homebrew 的 Node.js 和其他软件升级绑定在一起。

如果你已经使用 nvm、fnm 或 Volta 管理多个项目版本，请继续沿用原来的版本管理器，不要再叠加 .pkg。

4.1 确认 Mac 架构

打开"终端"，执行：

uname -m

输出含义：

• arm64：Apple Silicon；
• x86_64：Intel Mac，或者当前终端运行在 Rosetta 环境中。

还可以直接让系统显示硬件信息：

system_profiler SPHardwareDataType | grep -E "Chip|Processor Name"

4.2 下载并安装

访问：

https://nodejs.org/en/download

选择 LTS，并下载 macOS Installer。双击 .pkg 后按向导完成安装。

如果系统提示无法确认安装包来源，先核对文件是否确实来自 nodejs.org。不要为了绕过提示而全局关闭 Gatekeeper。

安装结束后，关闭并重新打开终端和 VS Code。

4.3 验证 macOS 环境

node -v
npm -v
npx -v
which -a node
which -a npm
node -p "process.platform + ' ' + process.arch"

Apple Silicon 原生运行时，最后一条通常输出：

darwin arm64

如果 which -a node 同时出现 /usr/local/bin/node、/opt/homebrew/bin/node 或版本管理器目录，说明电脑里可能存在多套 Node.js。先检查 shell 配置文件中的 PATH 顺序，再决定保留哪一套。

---

五、Linux 安装 Node.js

Linux 发行版很多，软件仓库中的 Node.js 版本也不一致。直接执行 apt install nodejs 或 dnf install nodejs 虽然方便，但得到的版本可能落后，nodejs 和 npm 还可能被拆成两个包。

本文使用 Node.js 官网发布的预编译二进制文件，并安装到当前用户目录。这样不依赖具体发行版，也不需要把文件写入 /usr/local。

如果你的团队已经统一使用 nvm、fnm、asdf、mise 或系统软件仓库，请遵守团队规范，不必换成本文方案。

5.1 检查系统架构

uname -m

常见对应关系：

x86_64  -> x64
aarch64 -> arm64
arm64   -> arm64

下面以 x64 和 Node.js v24.20.0 为例。如果官网 LTS 版本已经更新，请同步修改 NODE_VERSION；ARM64 设备把 NODE_ARCH 改为 arm64。

5.2 下载官方文件并校验 SHA-256

NODE_VERSION=v24.20.0
NODE_ARCH=x64

curl -O "https://nodejs.org/dist/${NODE_VERSION}/node-${NODE_VERSION}-linux-${NODE_ARCH}.tar.xz"
curl -O "https://nodejs.org/dist/${NODE_VERSION}/SHASUMS256.txt"

grep " node-${NODE_VERSION}-linux-${NODE_ARCH}.tar.xz$" SHASUMS256.txt | sha256sum -c -

最后应看到类似结果：

node-v24.20.0-linux-x64.tar.xz: OK

如果校验失败，不要继续解压。重新下载文件，并确认版本号、架构和下载来源都正确。

5.3 安装到当前用户目录

NODE_ROOT="$HOME/.local/lib/nodejs"

mkdir -p "$NODE_ROOT"
tar -xJf "node-${NODE_VERSION}-linux-${NODE_ARCH}.tar.xz" -C "$NODE_ROOT"
ln -sfn "$NODE_ROOT/node-${NODE_VERSION}-linux-${NODE_ARCH}" "$NODE_ROOT/current"

接着把下面一行加入当前 shell 的配置文件：

export PATH="$HOME/.local/lib/nodejs/current/bin:$PATH"

Bash 用户通常加入 ~/.bashrc，Zsh 用户通常加入 ~/.zshrc。修改完成后，重新打开终端，或者执行对应的加载命令：

source "$HOME/.bashrc"

Zsh 用户改为：

source "$HOME/.zshrc"

5.4 验证 Linux 环境

node -v
npm -v
npx -v
which -a node
which -a npm
node -p "process.platform + ' ' + process.arch"

常见 x64 Linux 输出为：

linux x64

这种安装方式通过 current 软链接指向实际版本。以后升级时，可以把新版本解压到同一目录，完成校验后再更新 current，不需要覆盖旧目录。

---

六、配置 npm 国内镜像

Node.js 安装完成后，npm 默认 Registry 是：

https://registry.npmjs.org/

在中国大陆网络环境中，如果访问官方 Registry 延迟高或经常超时，可以把依赖下载地址切换到 npmmirror：

https://registry.npmmirror.com/

注意，新地址不是早期教程里常见的 registry.npm.taobao.org。不要继续复制旧淘宝源地址。

6.1 先查看当前 Registry

Windows、macOS 和 Linux 使用同一条命令：

npm config get registry

再查看配置来自哪里：

npm config get userconfig
npm config get globalconfig
npm config list

这一步很重要。有时用户配置已经改回官方源，但项目根目录中的 .npmrc 又覆盖了它。只看用户级配置，很容易误判。

6.2 用户级切换：适合个人电脑

npm config set registry=https://registry.npmmirror.com/ --location=user

执行后验证：

npm config get registry
npm ping
npm view lodash version

预期第一条命令输出：

https://registry.npmmirror.com/

npm ping 用于检查 Registry 是否响应，npm view lodash version 则进一步验证包元数据能否正常读取。

6.3 只让当前项目使用镜像

进入包含 package.json 的项目根目录：

npm config set registry=https://registry.npmmirror.com/ --location=project

这会在当前项目的配置中记录 Registry。它适合团队明确约定使用同一镜像的情况。

但不要把"所有项目都必须使用某个公共镜像"当成默认规则。项目配置一旦提交到 Git，CI、海外开发者和公司内网环境也会受到影响。团队没有统一要求时，个人镜像优先放在用户级配置中。

6.4 只让一条命令临时使用镜像

不想改任何持久配置时，可以这样写：

npm install lodash --registry=https://registry.npmmirror.com/

这条命令结束后，其他 npm 命令仍使用原来的 Registry。排查问题和临时测试时，这种方式最干净。

6.5 恢复 npm 官方 Registry

npm config set registry=https://registry.npmjs.org/ --location=user
npm config get registry

如果曾在项目级配置中设置过镜像，需要进入该项目后单独删除：

npm config delete registry --location=project

不要只改用户级配置，却忘了项目级 .npmrc 的优先级更高。

6.6 三种配置范围怎么选？

范围	示例	影响范围	建议场景
单次命令	--registry=...	当前命令	临时测试、故障排查
项目级	--location=project	当前项目	团队明确统一源或使用私有源
用户级	--location=user	当前用户的大多数项目	个人开发机长期加速

---

七、安装 pnpm，并配置国内镜像

pnpm 不随 Node.js 自动安装。按照当前 pnpm 官方文档，如果通过 npm 路线安装 pnpm 11，需要 Node.js 22 或更高版本。本文使用的 Node.js 24 LTS 满足要求。

7.1 安装 pnpm

当前官方文档提供的 npm 安装入口是：

npx get-pnpm

安装完成后，关闭并重新打开终端，然后验证：

pnpm -v

如果系统仍提示找不到 pnpm，先检查实际命令位置。

Windows：

where.exe pnpm
Get-Command -All pnpm -ErrorAction SilentlyContinue

macOS / Linux：

which -a pnpm

截至本文验证日期，pnpm 12 已经发布，但 npm 的 latest 标签仍指向 pnpm 11，pnpm 12 使用单独的 next-12 安装入口。对普通项目来说，先使用默认稳定线更省心；需要 pnpm 12 时，应阅读它的版本差异说明后再切换，不要仅为了追新而升级包管理器。

7.2 为什么本文没有把 Corepack 作为默认方案？

Node.js 24 仍包含 Corepack，但 Node.js 从 25 开始不再随安装包分发 Corepack。也就是说，下面这种旧教程在不同 Node.js 版本上的结果已经不一致：

corepack enable

它不是错误命令，但不再适合作为跨版本教程的唯一安装路线。需要使用 Corepack 管理项目包管理器版本时，可以单独安装最新版 Corepack，并在项目 package.json 的 packageManager 字段中固定 pnpm 版本。

7.3 查看 pnpm 当前 Registry

pnpm config get registry

pnpm 能读取 npm 兼容配置中的 Registry 信息。如果你已经在用户级 .npmrc 中切换过 npm Registry，pnpm 可能已经显示同一个地址。因此先查看，再决定是否重复设置。

7.4 设置 pnpm 用户级镜像

pnpm config set registry https://registry.npmmirror.com/
pnpm config get registry
pnpm view lodash version

7.5 设置 pnpm 项目级镜像

进入项目根目录执行：

pnpm config set registry https://registry.npmmirror.com/ --location=project

与 npm 一样，项目级配置会影响其他开发者和 CI。只有团队明确需要时才提交这项配置。

7.6 临时指定 pnpm Registry

pnpm add lodash --registry=https://registry.npmmirror.com/

7.7 恢复 pnpm 官方 Registry

pnpm config set registry https://registry.npmjs.org/
pnpm config get registry

如果项目级配置仍然覆盖用户设置，在项目目录执行：

pnpm config delete registry --location=project

---

八、创建一个最小项目，完成闭环验证

只看到版本号还不够。真正完整的验证应该包括：初始化项目、下载依赖、执行依赖代码。

8.1 使用 npm 验证

mkdir node-env-npm-check
cd node-env-npm-check
npm init -y
npm install lodash
node -e "console.log(require('lodash').chunk([1, 2, 3, 4], 2))"

预期输出：

[ [ 1, 2 ], [ 3, 4 ] ]

8.2 使用 pnpm 验证

新建另一个目录，避免把 npm 和 pnpm 的锁文件混在一个测试项目里：

mkdir node-env-pnpm-check
cd node-env-pnpm-check
pnpm init
pnpm add lodash
node -e "console.log(require('lodash').chunk([1, 2, 3, 4], 2))"

预期输出同样是：

[ [ 1, 2 ], [ 3, 4 ] ]

到这里，下面这条链路才算全部通过：

操作系统找到 Node.js
        ↓
Node.js 能运行 JavaScript
        ↓
npm/pnpm 能访问 Registry
        ↓
依赖成功写入项目
        ↓
Node.js 能加载并执行依赖

---

九、镜像配置中的几个重要边界

镜像不是"设置一次，从此万事大吉"。下面几个边界最好一开始就知道。

9.1 安装依赖可以使用镜像，登录和发布要更谨慎

公共镜像主要用于读取包和下载文件。涉及账号登录、Token、发布和删除包时，应确认命令指向的是你真正信任的 Registry。

发布公开 npm 包时，可以显式指定官方地址：

npm publish --registry=https://registry.npmjs.org/

也可以在待发布包的 package.json 中固定发布目标：

{
  "publishConfig": {
    "registry": "https://registry.npmjs.org/"
  }
}

如果项目不应该被发布，应设置：

{
  "private": true
}

9.2 私有包要按 scope 配置 Registry

公司私有包通常使用 scope，例如 @company/design-system。这时不要让公共镜像接管私有包请求，而应为 scope 单独配置公司 Registry：

registry=https://registry.npmmirror.com/
@company:registry=https://npm.company.example/

认证 Token 必须绑定到对应 Registry，不能提交真实 Token：

//npm.company.example/:_authToken=${NPM_TOKEN}

需要注意：新版 pnpm 对项目级配置中的环境变量展开增加了安全限制。认证信息应放到可信的用户级配置、pnpm 的认证配置或 CI 密钥环境中，不要把 Token 写进项目仓库。

9.3 锁文件可能记录具体下载地址

npm 官方文档明确说明：使用默认 Registry 生成的锁文件通常可以跟随当前配置切换；如果锁文件是在自定义 Registry 下生成的，其中可能保留自定义地址，之后改回其他 Registry 仍可能继续访问旧地址。

遇到"已经换源，安装时却还在请求旧地址"时，先搜索锁文件中的 resolved 字段，不要第一反应就删除锁文件。

锁文件决定了可重复安装结果。团队项目中如需重新生成，应先确认依赖版本变化和安全影响，再由团队统一提交。

9.4 不要用关闭 TLS 校验来解决证书问题

下面这条命令经常出现在旧文章里：

npm config set strict-ssl=false

不建议这样做。它会关闭证书校验，使依赖下载更容易受到中间人攻击。

如果处于公司代理环境，应让网络管理员提供正确的代理地址或企业 CA 证书，然后配置 cafile。先检查电脑里是否残留旧代理：

npm config get proxy
npm config get https-proxy

确认已经不需要后再删除：

npm config delete proxy https-proxy

配置企业 CA 的示例：

npm config set cafile=/absolute/path/to/company-ca.pem

真实路径应指向经过组织确认的 CA 文件。

9.5 镜像提高可达性，不等于替代供应链安全

无论使用官方 Registry 还是镜像，都要保留以下习惯：

• 提交并审查 package-lock.json 或 pnpm-lock.yaml；
• CI 中使用 npm ci 或 pnpm install --frozen-lockfile；
• 定期执行依赖审计；
• 不随意执行来历不明的全局 CLI；
• 关注新依赖的维护者、发布时间、安装脚本和权限范围；
• 发布和认证操作显式核对 Registry。

速度问题不能用牺牲来源校验和凭据安全来解决。

---

十、常见问题排查

10.1 node 不是内部或外部命令 / command not found

先查系统到底能否找到命令。

Windows：

where.exe node
Get-Command -All node -ErrorAction SilentlyContinue

macOS / Linux：

which -a node
printf '%s\n' "$PATH"

处理顺序：

1. 关闭并重开终端；
2. 完全退出并重开 VS Code；
3. 检查安装目录是否在 PATH；
4. 检查是否存在多套 Node.js；
5. 通过原安装方式执行修复或重装。

10.2 终端版本正确，VS Code 里还是旧版本

VS Code 启动时会继承当时的环境变量。仅新开一个集成终端标签有时不够，应该完全退出 VS Code 后重新启动。

然后在 VS Code 终端中再次执行：

node -v
npm -v

10.3 npm install 卡住或超时

依次检查：

npm config get registry
npm ping
npm view lodash version
npm config get proxy
npm config get https-proxy
npm cache verify

不要一上来就执行 npm cache clean --force。npm 缓存具备内容校验机制，npm cache verify 更适合作为第一步。

需要观察请求细节时：

npm install --verbose

10.4 pnpm 下载慢，但 npm 已经换源

pnpm config get registry
pnpm config list

检查项目级配置是否覆盖用户级设置，并确认当前目录是否属于一个 pnpm workspace。

还可以查看 pnpm 存储位置与状态：

pnpm store path
pnpm store status

长期使用后如需清理没有被项目引用的包，可以执行：

pnpm store prune

它不等于删除所有缓存，也不需要每次安装前执行。

10.5 macOS / Linux 全局安装出现 EACCES

不要用 sudo npm install -g ... 作为通用解决办法。长期混用 sudo 会造成一部分文件属于 root、一部分属于当前用户，后续升级更难处理。

更稳妥的方案是：

• 使用 Node.js 版本管理器，让全局包安装在用户目录；
• 使用 npx 执行一次性工具；
• 将 npm 全局前缀改到用户目录；
• 对 pnpm 使用官方安装方式和用户级 PNPM_HOME。

10.6 Windows 提示 pnpm.ps1 无法加载

先验证命令本体：

pnpm.cmd -v

如果它能运行，说明 pnpm 已经安装，只是 PowerShell 脚本策略在生效。个人电脑可以评估后使用 CurrentUser + RemoteSigned，公司电脑遵循组织策略，不要擅自关闭安全限制。

10.7 Linux 运行 pnpm 提示缺少 libatomic.so.1

pnpm 官方文档指出，某些最小化 Linux 环境缺少 libatomic。Debian/Ubuntu 可以安装：

sudo apt-get install -y libatomic1

Fedora/RHEL 可以安装：

sudo dnf install -y libatomic

这类问题常见于精简容器或最小化系统镜像，普通桌面发行版通常已经具备所需运行库。

---

十一、一份可以直接照着核对的检查清单

Node.js

• 从可信来源安装受支持的 LTS；
• 架构与电脑一致；
• node -v、npm -v、npx -v 均能运行；
• where.exe node 或 which -a node 没有意外旧路径；
• VS Code 终端和系统终端版本一致。

npm

• npm config get registry 输出符合预期；
• npm ping 或 npm view lodash version 能完成；
• 知道当前配置是单次、项目级还是用户级；
• 没有为了图省事关闭 strict-ssl；
• 发布包前会显式确认官方或公司 Registry。

pnpm

• pnpm -v 能运行；
• pnpm config get registry 输出符合预期；
• 没有把 npm 与 pnpm 锁文件混用；
• CI 使用冻结锁文件安装；
• 知道 Node.js 25 以后不再内置 Corepack。

---

十二、最后总结

Node.js 环境搭建真正重要的，不是记住某一条换源命令，而是能回答下面四个问题：

1. 当前执行的是哪一个 Node.js？
2. 它是否仍处于官方支持周期？
3. npm 和 pnpm 实际访问的是哪个 Registry？
4. 如果镜像、代理或项目配置出了问题，能不能安全地恢复？

Windows 和 macOS 初次安装可以优先使用官方安装包；Linux 可以使用官方预编译文件、团队统一的版本管理器或合适的软件仓库。个人电脑需要国内加速时，优先使用用户级 Registry；团队项目则要谨慎评估项目级配置对 CI、私有包和海外开发者的影响。

一句话总结：安装要可验证，配置要分层，换源要能恢复，认证和发布要始终核对目标 Registry。

---

官方参考资料

• Node.js 官方下载页
• Node.js 版本与 LTS 状态
• npm config 官方文档
• npm 的 .npmrc 配置层级
• npm Registry 官方说明
• npm 全局安装 EACCES 权限问题
• pnpm 官方安装文档
• pnpm 配置文档
• pnpm 认证配置文档
• Corepack 项目说明

镜像地址

• npmmirror Registry