在 Windows 上用 npm 装个包，结果 PowerShell 窗口里蹦出一行红字：“npm : 无法加载文件 D:\Nodejs\node_global\npm.ps1，因为在此系统上禁止运行脚本”。这不是什么罕见问题，凡是在 Windows 下刚装完 Node.js、或者第一次在 VS Code 终端敲 npm 命令的人，十有八九撞到过同一堵墙。更气人的是，明明node -v都能正常输出版本号，偏偏 npm 一动就报错，看起来就像 Node 装坏了。我最早踩这个坑是在好几年前给一台新笔记本折腾开发环境的时候，后来又在公司电脑上遇到一次，这次就把完整的排查思路、解决方案和顺手能避开的坑都写出来。这篇文章适合所有使用 Windows 的 Node.js 开发者，也适合刚按着教程装完 Node.js 准备写第一个项目的新手，按顺序操作，基本能一次解决。
1. 先搞清楚：npm.ps1 为什么会被“禁止运行”
1.1 npm.ps1 是 PowerShell 版的 npm 启动脚本
首先要纠正一个常见误解：报错里提到的D:\Nodejs\node_global\npm.ps1并不是 npm 的核心程序。npm 真正的主程序是一个 JavaScript 文件，叫npm-cli.js，放在 Node.js 安装目录的node_modules\npm\bin下面。但 Windows 系统不能直接执行这种无扩展名的脚本文件，所以 npm 在安装时会生成几个“启动外壳”：
npm.cmd：供传统命令提示符（cmd.exe）使用的批处理启动器；npm.ps1：供 PowerShell 使用的 PowerShell 脚本；npm：供 Git Bash、WSL 这类 Unix 风格终端使用的无扩展名 shell 脚本。
PowerShell 在解析命令时，会优先在当前目录和 PATH 环境变量指定的路径中寻找可执行文件。如果目录里同时存在.cmd、.ps1等多个同名命令，PowerShell 会根据内置的优先级规则选中其中一个，通常最终命中的就是npm.ps1。也就是说，你遇到报错的这个文件，本身不是病毒，也不是损坏文件，它是 npm 在 PowerShell 环境下的“翻译官”。问题出在 PowerShell 这个解释器不打算放行它。
1.2 执行策略：Windows PowerShell 的安检门
“禁止运行脚本”这句话，精确地说，不是 npm 在拒绝你，而是 PowerShell 在执行策略层面拦截了所有.ps1文件。执行策略（Execution Policy）是 PowerShell 的一项安全机制，用来控制脚本能否在当前机器上运行。它的设计初衷很简单：防止用户在不知情的情况下运行来源不明的恶意脚本，和杀毒软件拦截未知程序是同一个思路。
Windows 10 / Windows 11 客户端系统默认的执行策略通常是 Restricted（受限模式），意思是：你可以一条一条地输入 PowerShell 命令，但不允许运行任何.ps1脚本文件。注意，这个策略对系统里所有脚本一视同仁，不区分是 npm 生成的还是从网上下载的。所以只要策略没放行，PowerShell 就会直接拒绝执行。
常见的执行策略一共有四种，我按安全程度从高到低给你捋一遍：
| 执行策略 | 含义 | 对 npm.ps1 的影响 |
|---|---|---|
| Restricted | 禁止运行任何脚本，只允许交互式命令 | npm.ps1 无法运行，报错 |
| RemoteSigned | 本地创建的脚本可运行；从互联网下载的脚本必须带有受信任的数字签名 | 本地安装的 npm.ps1 可以运行，最常见推荐方案 |
| AllSigned | 所有脚本，无论本地还是下载，都必须有受信任签名 | npm.ps1 若无签名仍会报错 |
| Unrestricted | 允许运行所有脚本，但下载脚本运行前会弹出提示 | 能运行，但安全门槛几乎形同虚设 |
打个生活化的比方：Restricted 相当于家里大门锁死，谁敲门都不开；RemoteSigned 是“认识的人随便进，陌生人必须出示身份证”；AllSigned 是“不管谁进门都要验身份证”；Unrestricted 基本等于门开着，基本安全都靠自觉。在解决 npm 问题这件事上，RemoteSigned 是性价比最高的选择：它能放行本地安装的脚本，同时保留对互联网下载脚本的拦截能力。
1.3 为什么 Node.js 装完还会踩坑
很多新手会问：既然 npm 是官方安装包自动生成的文件，为什么装完以后还是被拦？因为 Node.js 官方安装程序只负责把文件复制到磁盘、写注册表、配置基础 PATH，它没有权限也没有义务去修改 PowerShell 的执行策略。这属于操作系统的安全边界，安装程序不会越界改动。于是你装完 Node、打开 PowerShell、输入 npm，啪，撞上默认策略。这其实不是安装失败，而是“环境准备好了，但解释器不配合”。明白这一点，后面所有操作就都顺理成章了。
2. 最普遍适用的修复方案：把执行策略改成 RemoteSigned
2.1 操作步骤：管理员身份 + CurrentUser 作用域
网上搜这个报错，十个教程里九个会让你执行Set-ExecutionPolicy RemoteSigned，但他们往往没说清一个关键点：命令会影响哪个“作用域”。我建议第一步先看清楚当前策略状态，再动手。
先在开始菜单右键点击“Windows PowerShell（管理员）”或“终端（管理员）”，在弹出来的窗口里执行：
Get-ExecutionPolicy -List这条命令会列出所有作用域的执行策略，从机器级、用户级到当前会话级，覆盖优先级从上到下。你会看到类似这样的输出：
Scope ExecutionPolicy ----- -------------- MachinePolicy Undefined UserPolicy Undefined Process Undefined CurrentUser Undefined LocalMachine RestrictedLocalMachine那一行是Restricted，就说明限制来自机器级设置。接下来，执行：
Set-ExecutionPolicy -Scope CurrentUser RemoteSigned注意我特意加了-Scope CurrentUser，只对当前 Windows 用户生效，不影响系统里其他账户，也比直接改 Machine 级别更稳妥。执行后会问你“是否要更改执行策略”，输入Y回车。如果系统提示“拒绝访问”，说明当前 PowerShell 窗口没有管理员权限，需要重新以管理员身份打开再试。
改完以后，再跑一次：
Get-ExecutionPolicy -List确认CurrentUser变成了RemoteSigned，然后关掉 PowerShell 重新打开，输入npm -v。正常情况下就能看到版本号了。
注意：如果你只是想在某个临时会话里跑脚本、不想永久改策略，可以试试
Set-ExecutionPolicy -Scope Process Bypass。这只会对当前 PowerShell 窗口生效，窗口关掉就重置，适合临时绕过，但不适合作为日常 npm 长期使用的方案，因为你每次都要先设置一次，太折腾了。
2.2 RemoteSigned 和 Unrestricted 怎么选
很多教程随手就是一句Set-ExecutionPolicy Unrestricted，理由是“一步到位，以后什么脚本都能跑”。从解决眼前报错的角度看，确实一步到位了，但从长期角度看，我不建议新手这么干。
Unrestricted 意味着以后任何.ps1脚本都能直接运行，包括那些从网上下载的、带恶意行为的脚本。PowerShell 具备很强的系统管理能力，一个普通脚本可以删除文件、改注册表、连接网络。如果你平时经常从 GitHub 下载脚本直接跑，把策略设成 Unrestricted，等于给潜在风险开了绿灯。
RemoteSigned 的“聪明”之处在于：它区分脚本的“出生地”。npm 安装程序在本地生成的 npm.ps1 属于本地文件，不需要签名就能运行；而你在网上下载的 install.ps1、build.ps1 这类脚本，如果来源不受信任、没有数字签名，仍然会被拦截。这样 npm 这类正经工具能用，乱下载的东西该拦还是拦。所以，能用 RemoteSigned 就别用 Unrestricted，这是我换过几台电脑、踩过安全坑之后的真心话。
2.3 改完仍然失败的排查方向
设置完CurrentUser范围后依然报错，通常卡在两个地方。
第一种情况：机器级策略由组策略锁定。公司电脑上经常有 IT 部门统一配置安全策略，MachinePolicy或UserPolicy被强制设置了 Restricted。你可以用Get-ExecutionPolicy -List看一眼，如果MachinePolicy不是 Undefined，而是有具体值，那就说明组策略在顶层压着，单独改 CurrentUser 没用。这种情况，要么联系管理员申请放行，要么避开 PowerShell，改用命令提示符（CMD）里的 npm.cmd。
第二种情况：你改了当前用户执行策略，但实际用的终端会话没有刷新。VS Code 如果在改动前就打开了终端，或者 PowerShell 窗口一直在后台没关，它仍然沿用旧的策略值。别急着怀疑自己改错了，把所有相关终端窗口全部关闭，重新打开一个新的 PowerShell，再试一次npm -v。
第三种情况容易忽略：你运行的是 Windows PowerShell 5.1，但 VS Code 默认终端配置成了 PowerShell 7（pwsh.exe）。这两个解释器虽然名字相似，执行策略却是独立的进程级配置，修改完 Windows PowerShell 之后再在 pwsh 里测试，仍然可能报同样的错误。解决办法就是把当前用户策略设置好之后，在每个解释器里都验证一次。最稳妥的验证流程是：先Get-ExecutionPolicy -List查看，再在对应终端里执行Set-ExecutionPolicy -Scope CurrentUser RemoteSigned，最后重新打开终端。
3. 连带排查：Node.js 安装目录、npm 全局路径与 PATH 配置
3.1 先确认 node 和 npm 本身没问题
在执行策略放行之前，很多人会怀疑是不是 Node.js 安装有问题，其实node -v能输出版本号就说明 Node 本体没问题。执行策略问题解决后，再检查一条命令：
where node where npmwhere命令会列出系统搜索到的可执行文件完整路径。node应该指向你的 Node.js 安装目录，比如D:\Nodejs\node.exe。npm在 PowerShell 里通常会出现两条路径：一条是npm.ps1所在的 Node 安装目录或全局目录，一条是npm.cmd所在位置。看到两条路径并不意味着坏了，这属于正常现象。
但如果where npm一条都搜不到，说明 PATH 环境变量里没把 npm 所在目录包含进去。这通常是安装时没有勾选“Add to PATH”或者手动解压 Node 后没配环境变量导致的。这种情况下，即使执行策略放行，你输入 npm 也只会提示“不是内部或外部命令”。所以，能搜到文件，再讨论执行策略；搜不到文件，得先补环境变量。
3.2 npm 的 prefix 与全局目录
报错里出现了D:\Nodejs\node_global，这个路径大概率不是你随手写的，而是安装教程里要求手动配置过 npm 全局目录后的结果。npm 有个概念叫 prefix，它决定全局安装的包放在哪里。Windows 下默认的全局目录通常是C:\Users\你的用户名\AppData\Roaming\npm，但很多教程为了让全局包不占 C 盘，会让人把 prefix 改成 Node 安装目录下的某个子文件夹。
你可以用下面两条命令确认当前状态：
npm config get prefix npm root -g如果prefix指向D:\Nodejs\node_global，执行策略问题解决后，npm 会去这个目录找全局命令的启动脚本。假如这个目录不存在、或者里面没有生成npm.ps1，后续还会出现“找不到文件”之类的报错。处理办法是手动确认目录存在，然后再执行npm install -g npm@latest重新把 npm 自身装一遍，或者重新运行 Node.js 安装包做一次修复安装。
3.3 PATH 环境变量到底要不要动
设置完执行策略后，npm 本身能跑了，但一些安装在全局目录里的命令行工具（比如nodemon、vue、create-react-app）仍然提示“无法识别”，这就是 PATH 环境变量没配置完整。比如全局目录是D:\Nodejs\node_global，那 PATH 里必须包含这个目录，否则系统不知道去哪里找这些命令的启动文件。
打开环境变量设置的方法很简单：Win + R 输入sysdm.cpl，切到“高级”，点“环境变量”；或者在“设置”里搜索“编辑账户的环境变量”。在“系统变量”或“用户变量”的Path条目里新增两个路径：
- Node.js 安装根目录，例如
D:\Nodejs； - npm 全局模块目录，例如
D:\Nodejs\node_global。
这里有个经验之谈：把全局目录放在 Node.js 根目录前面。为什么？因为 Windows 按 PATH 顺序从前到后查找命令，如果两个目录里存在同名命令，排在前面先被找到。全局目录里的命令版本通常比 Node 根目录里的更多更新，放前面能减少版本冲突带来的奇怪问题。
改完 PATH 后记得关闭并重新打开终端，否则新的路径不会生效。想快速验证，可以执行：
echo %PATH%或者在 PowerShell 里用：
$env:Path -split ';'看到你新增的路径出现在列表中，就说明配置成功了。
3.4 npm 镜像源配置，顺手一起解决
执行策略修好、npm 能跑之后，紧跟着大概率会遇到的另一个问题是安装速度慢。npm 官方源在国外，国内网络环境访问时经常卡在 downloading 阶段，或者出现 ECONNRESET 之类的网络错误。这类问题属于网络范畴，和脚本执行策略无关，但既然都折腾到这一步了，顺手把镜像源也配上，省得一次一次等。
查看当前源：
npm config get registry如果输出的是https://registry.npmjs.org/，可以改成国内镜像源。比较常用的是 npmmirror（也就是早期大家常说的淘宝镜像）：
npm config set registry https://registry.npmmirror.com/配置完成后，再执行npm config get registry确认修改生效。改完源，npm install的速度通常会明显提升。注意，镜像源只影响 npm 下载包的速度，不解决任何脚本执行策略问题，别混淆。有些教程会把这件事和 npm.ps1 报错混在一起讲，实际上它们是两个独立问题，定位时先分清。
4. 各种变体场景：VS Code、CMD、CI 和 .bat 启动
4.1 在 CMD 里用 npm.cmd 可以绕开执行策略
如果你在公司电脑上，IT 策略锁得很死，改执行策略这条路走不通，另一个简单粗暴的办法是：不用 PowerShell，改用命令提示符（cmd.exe）。
按Win + R，输入cmd，回车，然后在 CMD 里直接输入npm -v。你会发现它能正常运行。原因很简单：CMD 执行的是npm.cmd这个批处理文件，批处理文件不归 PowerShell 的执行策略管。同样道理，如果你用 Git Bash、Windows Terminal 里的“命令提示符”配置文件，也不会遇到 npm.ps1 报错。
这个办法很实用，但有个小代价：CMD 的终端体验、自动补全和一些脚本语法跟 PowerShell 不一样。如果你习惯用 PowerShell，建议还是把执行策略改好；如果只是偶尔用一次 npm，CMD 完全够用。还有一种更精细的绕法：在 PowerShell 里显式调用 npm.cmd，强制绕开.ps1文件：
npm.cmd -v如果这个方法能成功，说明就是执行策略的锅，跟 Node 安装无关。
4.2 VS Code 终端里遇到的同样问题
VS Code 默认终端在 Windows 上通常集成的是 PowerShell，所以你在 VS Code 里按 Ctrl + ` 打开终端，输入 npm，看到的报错和系统 PowerShell 一模一样。解决办法就是第 2 节里说的，在系统层面把执行策略改成 RemoteSigned，然后完全关闭 VS Code，重新打开。不要只关闭终端面板再打开一个新的，那样进程可能还在复用旧环境。整个 VS Code 退出重启，保证它重新读取执行策略。
还有一个细节：VS Code 的默认终端配置文件是可以切换的。如果你不想改执行策略，可以点终端窗口右侧的下拉箭头，把默认配置文件改成“命令提示符 cmd”或“Git Bash”，然后再打开终端，输入 npm。这样 VS Code 内部直接调用 npm.cmd，不经过 PowerShell，也能避开限制。这个功能对我来说非常实用，特别是帮同事排查问题时，不强制改别人电脑上的安全设置。
4.3 npx、node-gyp 和本地 .ps1 脚本
执行策略影响的不仅是 npm 本身，凡是需要以.ps1脚本形式运行的命令都会中招。比如：
npx create-react-app my-app：npx 在 Windows 下也可能生成临时.ps1启动文件；- 从 GitHub 上拉下来的
install.ps1、setup.ps1等脚本； - 一些自动化构建脚本里直接调用
.\xxx.ps1。
针对这些情况，除了全局修改执行策略，还有两种临时方案值得记住。
第一种，当前会话临时放行：
Set-ExecutionPolicy -Scope Process Bypass执行后当前 PowerShell 窗口不再拦截脚本，窗口关闭后策略自动恢复，适合临时跑一个脚本。
第二种，从命令行以参数形式声明“本次运行放行”，不改变任何系统设置：
powershell -ExecutionPolicy Bypass -File install.ps1这条命令在 cmd 或 PowerShell 里都能用，它启动一个新的 PowerShell 进程，仅对该进程放行脚本，安全且干净。我经常在 CI 环境或者服务器上跑自动化脚本时用这个方式，既绕开了系统默认限制，又不会污染服务器的全局配置。
4.4 用 .bat 启动 Node 服务的小技巧
热词里还有一个“建一个 .bat 文件在桌面运行 nodejs 打开服务”的需求，这类场景也容易和 npm.ps1 混在一起。如果你写了一个.bat文件，内容比如：
cd /d D:\my-project npm start在 CMD 里双击运行这个批处理，用的是 cmd 解释器，npm 走的是npm.cmd，一般不会触发 PowerShell 执行策略。但如果你在批处理里写的是：
powershell -Command "npm start"那还是会绕回 PowerShell，面临同样的策略问题。所以写 .bat 启动脚本时，直接用npm start，别在中间套一层 PowerShell，更省心。如果必须用 PowerShell 执行项目脚本，就在 .bat 里带上-ExecutionPolicy Bypass参数：
powershell -ExecutionPolicy Bypass -Command "npm start"这样既保留了 PowerShell 的能力，也不会被策略卡住。
5. 高频问题排查速查表与避坑经验
5.1 报错后还有哪些典型症状
每次帮人排查这类问题，我都会把故障现象、可能原因和处理手段列成一张速查表，方便大家对照定位。下面的表格就是我实际项目中常用的排查模板：
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| PowerShell 运行任何 .ps1 都报“禁止运行脚本” | 默认 Restricted 策略或组策略锁定 | 设置 CurrentUser 为 RemoteSigned；若仍失败，检查 MachinePolicy |
| 改了 CurrentUser 策略，新终端仍然报错 | VS Code / PowerShell 7 进程未重启 | 关闭所有终端和 VS Code 后重开；检查执行策略作用域是否为 CurrentUser |
| npm -v 报“不是内部或外部命令” | PATH 未包含 Node 根目录或 npm 全局目录 | 用 where npm 定位，补全 PATH 后重启终端 |
| npm install 很慢或断连 | 镜像源为官方源 | npm config set registry https://registry.npmmirror.com/ |
| 全局安装的命令找不到 | PATH 未包含全局目录 | 添加 prefix 对应路径，并放在 Node 根目录前面 |
| 项目里执行 install.ps1 报错 | 下载脚本被 RemoteSigned 拦截 | powershell -ExecutionPolicy Bypass -File install.ps1 |
| npx 创建项目失败 | npx 生成的 .ps1 也被策略拦截 | 与 npm 同样处理；或临时 Process Bypass |
| npm uninstall -g 卸载全局包后命令还在 | prefix 路径或缓存混乱 | npm config get prefix 确认全局目录，删除多余目录文件或用 npm uninstall -g 包名 再验证 |
5.2 别删 npm.ps1，也别重装 Node 解决一切
遇到报错时，有一部分人会想：既然npm.ps1这个文件“有问题”，那我直接把它删了行不行？真的不要删。删掉之后，PowerShell 里输入 npm 会直接找不到命令，因为 Windows 的可执行文件搜索机制里没有这个启动脚本了。正确的做法是放行策略，或者用 CMD 里的 npm.cmd，而不是从文件层面“消灭”它。
还有一种极端操作是直接重装 Node.js。如果只是执行策略问题，重装十次也没用，因为安装程序不会帮你改策略。如果node -v正常但 npm 老报错，先花两分钟按上面步骤验证执行策略和 PATH，基本都能定位。重装 Node 只有在 npm 文件确实损坏、目录结构异常时才值得尝试，而且重装前最好把之前改过的~/.npmrc备份一下。
5.3 执行策略的安全边界与日常习惯
最后提醒一件事：执行策略是 Windows 安全机制的一部分，不是摆设。我见过一些同学为了“省事”，把策略设成 Unrestricted，结果后来误跑了一个可疑的.ps1，引起不小的麻烦。日常工作中，尽量保持 RemoteSigned 这个度，既不影响开发效率，又保留了对下载脚本的拦截。如果某个脚本确实来源可靠、可以信任，再单独对它做测试放行，也比全局大开方便门稳妥。
5.4 我的一点实操心得
从我自己的使用习惯来说，Windows 开发机上遇到这个报错，我基本都是执行Set-ExecutionPolicy -Scope CurrentUser RemoteSigned一次搞定，然后顺手把 npm 镜像源改成国内源，再把全局目录的 PATH 检查一遍。这三件事做完，Windows 下的 Node.js 开发体验基本就顺畅了，后面再装全局包、跑脚本、用 npx，都很少再被环境问题卡住。如果你现在正被这行红字搞得很烦躁，别怀疑自己装错了什么，按第 2 节的步骤先改执行策略，八成直接就好了。
