1. 为什么 Windows 上的 Node.js 安装总有人翻车Node.js 在 Windows 上的安装表面上看就是下载一个安装包、一路点“下一步”的事但实际带过新人的都知道这一步翻车率出奇地高。有人装完之后node -v能出版本号npm -v却报“无法加载文件 npm.ps1因为在此系统上禁止运行脚本”有人全局装了个包命令行里敲名字提示“不是内部或外部命令”还有人npm install卡在某个包上十几分钟不动最后超时失败。这些问题的根源八成不在 Node.js 本身而在环境变量、PowerShell 执行策略、镜像源这三件事上。这篇内容面向的是刚在 Windows 上接触 Node.js 的开发者和运维同学也适合那些“装过但没装明白”的人。我会把安装路径选择、环境变量到底改了哪几个、npm 全局目录怎么规划、镜像源怎么配、PowerShell 报错怎么修一条链路讲透。核心关键词就几个windows、node.js、npm、环境变量、镜像源。你把这五件事理顺了后面无论是跑前端项目、写脚本工具还是发布自己的 npm 包都不会再被环境问题绊住。先说一个反直觉的结论Node.js 官方安装包默认帮你配好的环境变量恰恰是后面很多坑的源头。它会把 npm 全局包目录塞进用户目录下的AppData\Roaming\npm这个路径又长又带空格一旦你后面用某些工具链路径解析就容易出问题。所以真正稳妥的做法不是无脑下一步而是在安装时就规划好目录结构。2. 安装前的目录规划与版本选择2.1 安装路径为什么不要用默认的 Program Files官方安装包默认装到C:\Program Files\nodejs\。这个路径本身没问题问题在于它带空格。Node.js 核心对空格路径是能处理的但生态里大量第三方工具、构建脚本、老旧的 npm 包在拼接命令行时不做引号转义路径里的空格就会把参数切断。我见过最典型的是某些 node-gyp 编译原生模块的场景路径带空格直接编译失败报错信息还特别隐晦查半天才反应过来是空格惹的祸。我的建议是装到C:\nodejs\或者D:\dev\nodejs\这种纯英文、无空格、层级浅的目录。层级浅还有个好处Windows 的路径长度历史上有限制虽然新版已经放开但很多工具链仍按老规矩来路径越短越不容易触发“文件名或扩展名太长”的问题。2.2 LTS 还是 Current别纠结太久Node.js 官网下载页会给两个版本LTS长期支持版和 Current最新特性版。新手直接选 LTS没有例外。LTS 意味着这个版本会持续收到安全更新和 bug 修复生态里的包对它兼容性验证最充分。Current 版本会引入新的 V8 引擎和实验性 API某些 npm 包还没跟上你装完跑项目可能直接报The requested module node:util does not provide an export named...这类模块导出错误——这通常就是版本和依赖不匹配导致的。判断标准很简单你要跑的是生产项目、公司项目、学习用途一律 LTS。只有当你明确需要某个只有新版本才有的特性并且愿意承担兼容风险时才上 Current。截至我写这篇内容时Node.js 18 和 20 都是 LTS 线选哪个看你的项目依赖要求一般选更新的 LTS 更省心。2.3 安装向导里那个勾选项决定了很多事安装向导走到某一步会问你要不要勾选 “Automatically install the necessary tools”还会问要不要把 Node.js 加到 PATH。这里有两个决策点Add to PATH必须勾。这是让node和npm命令能在任意目录下被找到的前提。Automatically install the necessary tools这个选项会额外下载 Python、Visual Studio Build Tools 等一堆东西体积大、耗时长。如果你只是做前端开发、写写脚本用不到原生模块编译可以不勾后面真需要了再单独装。勾了的话安装过程可能卡在下载环节让人以为装挂了。提示如果你之前装过旧版本 Node.js务必先通过“应用和功能”卸载干净再装新版本。残留的旧目录和旧环境变量会导致版本混乱node -v出来的版本和你以为的对不上。3. 环境变量到底改了哪几个逐个说清楚3.1 PATH 里那两条记录分别管什么安装完成后打开“系统属性 → 高级 → 环境变量”你会看到用户变量或系统变量的 PATH 里多了两条C:\nodejs\ C:\Users\你的用户名\AppData\Roaming\npm第一条让系统能找到node.exe和npm.cmd这是 Node.js 本体和 npm 命令的入口。第二条是 npm 全局包的安装位置你npm install -g装的每个包可执行文件都落在这个目录里PATH 里有它你才能全局调用这些命令。很多人全局装完包提示“不是内部或外部命令”就是第二条没配好或者配了但没重启命令行窗口。环境变量的修改对已经打开的终端不生效必须关掉重开。3.2 手动验证环境变量是否生效装完之后别急着跑项目先做三步验证node -v npm -v where node where npm前两条出版本号说明命令可用。where命令会列出系统实际找到的可执行文件路径如果它指向的不是你刚装的目录说明 PATH 里有更靠前的旧版本记录需要手动调整顺序或清理旧记录。这一步能提前暴露 90% 的“装了但用不了”问题。3.3 全局包目录和缓存目录的重新规划前面说过默认的全局目录在AppData\Roaming\npm路径长且带用户目录。我习惯把它挪到更规整的位置比如D:\dev\node-global缓存目录挪到D:\dev\node-cache。这样做的好处是备份、迁移、清理都方便重装系统时这些目录可以保留。配置方式是在命令行执行npm config set prefix D:\dev\node-global npm config set cache D:\dev\node-cache执行完记得把D:\dev\node-global加进 PATH同时把原来那条AppData\Roaming\npm从 PATH 里删掉避免两个全局目录打架。改完之后重开终端再npm install -g装个包测试用where确认可执行文件落在新目录里。注意npm config set prefix改的是 npm 的全局安装位置但node.exe本身的位置不受影响。别把这两个概念搞混Node.js 本体还是在你最初安装的目录。4. npm 镜像源不配它安装速度能差十倍4.1 默认源为什么慢npm 默认从官方 registry 拉包服务器在境外。国内网络环境下拉取小包还能忍一旦遇到依赖树庞大的项目几百个包挨个请求速度慢不说还经常中途超时失败报ETIMEDOUT或ECONNRESET。这不是你网络的问题是物理距离和链路质量决定的。解决办法就是换国内镜像源。镜像源会定期同步官方 registry 的内容你从镜像拉包相当于就近取货速度提升非常明显。常用的有淘宝镜像npmmirror等选一个稳定的即可。4.2 配置镜像源的两种方式方式一全局配置一劳永逸npm config set registry https://registry.npmmirror.com配完之后用npm config get registry确认输出应该是你设置的地址。这种方式对所有项目生效适合个人开发机。方式二项目级配置按需切换在项目根目录建一个.npmrc文件写入registryhttps://registry.npmmirror.com这种方式只对当前项目生效适合团队协作时统一环境或者你需要在不同项目用不同源的情况。项目级配置优先级高于全局配置。4.3 换源之后可能遇到的新问题换源不是万能的有两个坑要提前知道。第一镜像同步有延迟。你刚发布的包或者某个包刚发新版本镜像可能还没同步过来这时候npm install会报 404。解决办法是临时切回官方源装这一个包或者等几分钟再试。第二某些包在镜像上不完整。极少数包因为各种原因没被完整同步安装时会报校验失败。遇到这种情况同样临时切官方源解决。切换命令很简单npm config set registry https://registry.npmjs.org # 装完再切回来 npm config set registry https://registry.npmmirror.com我个人的习惯是全局配镜像源遇到个别包拉不下来时临时切官方源装完立刻切回。这样兼顾了日常速度和特殊情况。5. PowerShell 报“禁止运行脚本”的完整排查链路5.1 这个报错到底在说什么在 PowerShell 里敲npm -v报出这么一串npm : 无法加载文件 C:\Program Files\nodejs\npm.ps1因为在此系统上禁止运行脚本。很多人第一反应是 Node.js 装坏了其实不是。这是 PowerShell 的**执行策略Execution Policy**在拦你。PowerShell 出于安全考虑默认不允许运行.ps1脚本文件而 npm 在 PowerShell 里的入口恰好就是一个.ps1脚本。命令提示符cmd里没这个问题因为 cmd 走的是npm.cmd。5.2 查看当前执行策略先确认现状在 PowerShell 里执行Get-ExecutionPolicy大概率输出Restricted意思是不允许任何脚本运行。也可能是Undefined表示没设置过继承上级策略。5.3 修改执行策略的正确姿势修改执行策略需要管理员权限的 PowerShell。以管理员身份打开 PowerShell执行Set-ExecutionPolicy RemoteSignedRemoteSigned的含义是本地写的脚本可以直接跑从网络下载的脚本需要有数字签名才能跑。这个策略在安全性和可用性之间取得了平衡是官方推荐的开发机设置。执行后会提示确认输入Y回车。改完再用Get-ExecutionPolicy确认应该显示RemoteSigned。然后关掉所有 PowerShell 窗口重开再敲npm -v问题解决。提示不要用Set-ExecutionPolicy Unrestricted那等于把所有脚本限制都关了安全性太差。RemoteSigned足够日常开发使用。5.4 为什么 cmd 里没事PowerShell 里就报错这是很多人困惑的点。本质是两种终端加载 npm 的入口文件不同cmd 找的是npm.cmdPowerShell 优先找npm.ps1。.cmd是批处理文件不受 PowerShell 执行策略管辖.ps1是 PowerShell 脚本受管辖。所以同一个 npm在不同终端里表现不一样。理解了这一点以后遇到类似“某个命令在 A 终端能用、B 终端不能用”的情况就知道往执行策略或入口文件方向查。6. 装完之后必须做的几项验证与常见故障对照6.1 从零到跑通一个项目的完整验证环境配好之后别急着上大项目先用最小成本验证整条链路。找个空目录执行mkdir test-node cd test-node npm init -y npm install lodash node -e const _ require(lodash); console.log(_.chunk([1,2,3,4], 2))这段操作覆盖了 npm 初始化、从镜像源装包、Node.js 加载第三方模块三个环节。如果最后输出[ [ 1, 2 ], [ 3, 4 ] ]说明你的 Node.js、npm、镜像源、环境变量全部正常。任何一步报错对照下面的表格排查。6.2 常见故障速查表现象大概率原因处理方式node不是内部或外部命令PATH 没配或没生效检查 PATH重开终端npm -v报禁止运行脚本PowerShell 执行策略限制管理员 PowerShell 设 RemoteSigned全局包装了但命令找不到全局目录不在 PATH把 npm prefix 目录加进 PATHnpm install卡住或超时用的官方源换国内镜像源装包报 404镜像未同步临时切官方源装完再切回版本号和预期不符旧版本残留卸载旧版清理 PATH 旧记录原生模块编译失败缺构建工具或路径带空格装 Build Tools换无空格路径6.3 几个容易被忽略的实操心得第一改完环境变量一定要重开终端。这是最高频的“假故障”很多人改完发现没生效其实是当前终端还在用旧的环境变量快照。第二npm config的配置存在用户目录的.npmrc里换机器时把这个文件带走能省去重新配置的麻烦。想看当前所有配置执行npm config list。第三多版本 Node.js 共存要用版本管理工具。如果你同时维护几个要求不同 Node.js 版本的项目手动切换安装包太痛苦。Windows 上可以用 nvm-windows 这类工具一条命令切换版本。但要注意nvm-windows 切换版本时会接管 PATH和你手动配的环境变量可能冲突用之前先把手动配的清理干净。第四公司内网环境可能有自己的私有源。如果你在公司网络里先问清楚有没有内部 npm 源配错了源可能连包都拉不到。私有源的配置方式和公共镜像一样只是地址不同。7. 关于镜像源和环境的几句实在话镜像源这件事配一次能省下大量等待时间但别把它当成万能药。它的本质是缓存代理缓存就有同步延迟就有覆盖不全的可能。所以正确的姿势是日常用镜像源提速遇到拉不下来的包临时切官方源装完切回。这个切换成本很低一条命令的事但能避免很多“为什么这个包装不上”的困惑。环境变量这块核心就理解两件事PATH 决定系统去哪找命令npm 的 prefix 决定全局包装到哪。把这两个概念理清以后遇到任何“命令找不到”或“包装了但用不了”的问题你都能自己定位。我见过太多人一遇到环境问题就重装系统、重装 Node.js其实九成情况改一条 PATH 记录就解决了。最后说个我自己的习惯每配好一台新机器的开发环境我会把关键的配置命令记在一个setup.md里包括 npm 源地址、全局目录路径、执行策略设置。下次换机器或者帮同事配环境直接照着敲一遍五分钟搞定不用再回忆当初踩了哪些坑。环境配置这种事一次做对后面就是纯收益。
Windows 上 Node.js 安装避坑指南：环境变量、镜像源与 PowerShell 执行策略
1. 为什么 Windows 上的 Node.js 安装总有人翻车Node.js 在 Windows 上的安装表面上看就是下载一个安装包、一路点“下一步”的事但实际带过新人的都知道这一步翻车率出奇地高。有人装完之后node -v能出版本号npm -v却报“无法加载文件 npm.ps1因为在此系统上禁止运行脚本”有人全局装了个包命令行里敲名字提示“不是内部或外部命令”还有人npm install卡在某个包上十几分钟不动最后超时失败。这些问题的根源八成不在 Node.js 本身而在环境变量、PowerShell 执行策略、镜像源这三件事上。这篇内容面向的是刚在 Windows 上接触 Node.js 的开发者和运维同学也适合那些“装过但没装明白”的人。我会把安装路径选择、环境变量到底改了哪几个、npm 全局目录怎么规划、镜像源怎么配、PowerShell 报错怎么修一条链路讲透。核心关键词就几个windows、node.js、npm、环境变量、镜像源。你把这五件事理顺了后面无论是跑前端项目、写脚本工具还是发布自己的 npm 包都不会再被环境问题绊住。先说一个反直觉的结论Node.js 官方安装包默认帮你配好的环境变量恰恰是后面很多坑的源头。它会把 npm 全局包目录塞进用户目录下的AppData\Roaming\npm这个路径又长又带空格一旦你后面用某些工具链路径解析就容易出问题。所以真正稳妥的做法不是无脑下一步而是在安装时就规划好目录结构。2. 安装前的目录规划与版本选择2.1 安装路径为什么不要用默认的 Program Files官方安装包默认装到C:\Program Files\nodejs\。这个路径本身没问题问题在于它带空格。Node.js 核心对空格路径是能处理的但生态里大量第三方工具、构建脚本、老旧的 npm 包在拼接命令行时不做引号转义路径里的空格就会把参数切断。我见过最典型的是某些 node-gyp 编译原生模块的场景路径带空格直接编译失败报错信息还特别隐晦查半天才反应过来是空格惹的祸。我的建议是装到C:\nodejs\或者D:\dev\nodejs\这种纯英文、无空格、层级浅的目录。层级浅还有个好处Windows 的路径长度历史上有限制虽然新版已经放开但很多工具链仍按老规矩来路径越短越不容易触发“文件名或扩展名太长”的问题。2.2 LTS 还是 Current别纠结太久Node.js 官网下载页会给两个版本LTS长期支持版和 Current最新特性版。新手直接选 LTS没有例外。LTS 意味着这个版本会持续收到安全更新和 bug 修复生态里的包对它兼容性验证最充分。Current 版本会引入新的 V8 引擎和实验性 API某些 npm 包还没跟上你装完跑项目可能直接报The requested module node:util does not provide an export named...这类模块导出错误——这通常就是版本和依赖不匹配导致的。判断标准很简单你要跑的是生产项目、公司项目、学习用途一律 LTS。只有当你明确需要某个只有新版本才有的特性并且愿意承担兼容风险时才上 Current。截至我写这篇内容时Node.js 18 和 20 都是 LTS 线选哪个看你的项目依赖要求一般选更新的 LTS 更省心。2.3 安装向导里那个勾选项决定了很多事安装向导走到某一步会问你要不要勾选 “Automatically install the necessary tools”还会问要不要把 Node.js 加到 PATH。这里有两个决策点Add to PATH必须勾。这是让node和npm命令能在任意目录下被找到的前提。Automatically install the necessary tools这个选项会额外下载 Python、Visual Studio Build Tools 等一堆东西体积大、耗时长。如果你只是做前端开发、写写脚本用不到原生模块编译可以不勾后面真需要了再单独装。勾了的话安装过程可能卡在下载环节让人以为装挂了。提示如果你之前装过旧版本 Node.js务必先通过“应用和功能”卸载干净再装新版本。残留的旧目录和旧环境变量会导致版本混乱node -v出来的版本和你以为的对不上。3. 环境变量到底改了哪几个逐个说清楚3.1 PATH 里那两条记录分别管什么安装完成后打开“系统属性 → 高级 → 环境变量”你会看到用户变量或系统变量的 PATH 里多了两条C:\nodejs\ C:\Users\你的用户名\AppData\Roaming\npm第一条让系统能找到node.exe和npm.cmd这是 Node.js 本体和 npm 命令的入口。第二条是 npm 全局包的安装位置你npm install -g装的每个包可执行文件都落在这个目录里PATH 里有它你才能全局调用这些命令。很多人全局装完包提示“不是内部或外部命令”就是第二条没配好或者配了但没重启命令行窗口。环境变量的修改对已经打开的终端不生效必须关掉重开。3.2 手动验证环境变量是否生效装完之后别急着跑项目先做三步验证node -v npm -v where node where npm前两条出版本号说明命令可用。where命令会列出系统实际找到的可执行文件路径如果它指向的不是你刚装的目录说明 PATH 里有更靠前的旧版本记录需要手动调整顺序或清理旧记录。这一步能提前暴露 90% 的“装了但用不了”问题。3.3 全局包目录和缓存目录的重新规划前面说过默认的全局目录在AppData\Roaming\npm路径长且带用户目录。我习惯把它挪到更规整的位置比如D:\dev\node-global缓存目录挪到D:\dev\node-cache。这样做的好处是备份、迁移、清理都方便重装系统时这些目录可以保留。配置方式是在命令行执行npm config set prefix D:\dev\node-global npm config set cache D:\dev\node-cache执行完记得把D:\dev\node-global加进 PATH同时把原来那条AppData\Roaming\npm从 PATH 里删掉避免两个全局目录打架。改完之后重开终端再npm install -g装个包测试用where确认可执行文件落在新目录里。注意npm config set prefix改的是 npm 的全局安装位置但node.exe本身的位置不受影响。别把这两个概念搞混Node.js 本体还是在你最初安装的目录。4. npm 镜像源不配它安装速度能差十倍4.1 默认源为什么慢npm 默认从官方 registry 拉包服务器在境外。国内网络环境下拉取小包还能忍一旦遇到依赖树庞大的项目几百个包挨个请求速度慢不说还经常中途超时失败报ETIMEDOUT或ECONNRESET。这不是你网络的问题是物理距离和链路质量决定的。解决办法就是换国内镜像源。镜像源会定期同步官方 registry 的内容你从镜像拉包相当于就近取货速度提升非常明显。常用的有淘宝镜像npmmirror等选一个稳定的即可。4.2 配置镜像源的两种方式方式一全局配置一劳永逸npm config set registry https://registry.npmmirror.com配完之后用npm config get registry确认输出应该是你设置的地址。这种方式对所有项目生效适合个人开发机。方式二项目级配置按需切换在项目根目录建一个.npmrc文件写入registryhttps://registry.npmmirror.com这种方式只对当前项目生效适合团队协作时统一环境或者你需要在不同项目用不同源的情况。项目级配置优先级高于全局配置。4.3 换源之后可能遇到的新问题换源不是万能的有两个坑要提前知道。第一镜像同步有延迟。你刚发布的包或者某个包刚发新版本镜像可能还没同步过来这时候npm install会报 404。解决办法是临时切回官方源装这一个包或者等几分钟再试。第二某些包在镜像上不完整。极少数包因为各种原因没被完整同步安装时会报校验失败。遇到这种情况同样临时切官方源解决。切换命令很简单npm config set registry https://registry.npmjs.org # 装完再切回来 npm config set registry https://registry.npmmirror.com我个人的习惯是全局配镜像源遇到个别包拉不下来时临时切官方源装完立刻切回。这样兼顾了日常速度和特殊情况。5. PowerShell 报“禁止运行脚本”的完整排查链路5.1 这个报错到底在说什么在 PowerShell 里敲npm -v报出这么一串npm : 无法加载文件 C:\Program Files\nodejs\npm.ps1因为在此系统上禁止运行脚本。很多人第一反应是 Node.js 装坏了其实不是。这是 PowerShell 的**执行策略Execution Policy**在拦你。PowerShell 出于安全考虑默认不允许运行.ps1脚本文件而 npm 在 PowerShell 里的入口恰好就是一个.ps1脚本。命令提示符cmd里没这个问题因为 cmd 走的是npm.cmd。5.2 查看当前执行策略先确认现状在 PowerShell 里执行Get-ExecutionPolicy大概率输出Restricted意思是不允许任何脚本运行。也可能是Undefined表示没设置过继承上级策略。5.3 修改执行策略的正确姿势修改执行策略需要管理员权限的 PowerShell。以管理员身份打开 PowerShell执行Set-ExecutionPolicy RemoteSignedRemoteSigned的含义是本地写的脚本可以直接跑从网络下载的脚本需要有数字签名才能跑。这个策略在安全性和可用性之间取得了平衡是官方推荐的开发机设置。执行后会提示确认输入Y回车。改完再用Get-ExecutionPolicy确认应该显示RemoteSigned。然后关掉所有 PowerShell 窗口重开再敲npm -v问题解决。提示不要用Set-ExecutionPolicy Unrestricted那等于把所有脚本限制都关了安全性太差。RemoteSigned足够日常开发使用。5.4 为什么 cmd 里没事PowerShell 里就报错这是很多人困惑的点。本质是两种终端加载 npm 的入口文件不同cmd 找的是npm.cmdPowerShell 优先找npm.ps1。.cmd是批处理文件不受 PowerShell 执行策略管辖.ps1是 PowerShell 脚本受管辖。所以同一个 npm在不同终端里表现不一样。理解了这一点以后遇到类似“某个命令在 A 终端能用、B 终端不能用”的情况就知道往执行策略或入口文件方向查。6. 装完之后必须做的几项验证与常见故障对照6.1 从零到跑通一个项目的完整验证环境配好之后别急着上大项目先用最小成本验证整条链路。找个空目录执行mkdir test-node cd test-node npm init -y npm install lodash node -e const _ require(lodash); console.log(_.chunk([1,2,3,4], 2))这段操作覆盖了 npm 初始化、从镜像源装包、Node.js 加载第三方模块三个环节。如果最后输出[ [ 1, 2 ], [ 3, 4 ] ]说明你的 Node.js、npm、镜像源、环境变量全部正常。任何一步报错对照下面的表格排查。6.2 常见故障速查表现象大概率原因处理方式node不是内部或外部命令PATH 没配或没生效检查 PATH重开终端npm -v报禁止运行脚本PowerShell 执行策略限制管理员 PowerShell 设 RemoteSigned全局包装了但命令找不到全局目录不在 PATH把 npm prefix 目录加进 PATHnpm install卡住或超时用的官方源换国内镜像源装包报 404镜像未同步临时切官方源装完再切回版本号和预期不符旧版本残留卸载旧版清理 PATH 旧记录原生模块编译失败缺构建工具或路径带空格装 Build Tools换无空格路径6.3 几个容易被忽略的实操心得第一改完环境变量一定要重开终端。这是最高频的“假故障”很多人改完发现没生效其实是当前终端还在用旧的环境变量快照。第二npm config的配置存在用户目录的.npmrc里换机器时把这个文件带走能省去重新配置的麻烦。想看当前所有配置执行npm config list。第三多版本 Node.js 共存要用版本管理工具。如果你同时维护几个要求不同 Node.js 版本的项目手动切换安装包太痛苦。Windows 上可以用 nvm-windows 这类工具一条命令切换版本。但要注意nvm-windows 切换版本时会接管 PATH和你手动配的环境变量可能冲突用之前先把手动配的清理干净。第四公司内网环境可能有自己的私有源。如果你在公司网络里先问清楚有没有内部 npm 源配错了源可能连包都拉不到。私有源的配置方式和公共镜像一样只是地址不同。7. 关于镜像源和环境的几句实在话镜像源这件事配一次能省下大量等待时间但别把它当成万能药。它的本质是缓存代理缓存就有同步延迟就有覆盖不全的可能。所以正确的姿势是日常用镜像源提速遇到拉不下来的包临时切官方源装完切回。这个切换成本很低一条命令的事但能避免很多“为什么这个包装不上”的困惑。环境变量这块核心就理解两件事PATH 决定系统去哪找命令npm 的 prefix 决定全局包装到哪。把这两个概念理清以后遇到任何“命令找不到”或“包装了但用不了”的问题你都能自己定位。我见过太多人一遇到环境问题就重装系统、重装 Node.js其实九成情况改一条 PATH 记录就解决了。最后说个我自己的习惯每配好一台新机器的开发环境我会把关键的配置命令记在一个setup.md里包括 npm 源地址、全局目录路径、执行策略设置。下次换机器或者帮同事配环境直接照着敲一遍五分钟搞定不用再回忆当初踩了哪些坑。环境配置这种事一次做对后面就是纯收益。
