PowerShell 执行策略导致 npm 报错？一文教你彻底解决

刚装完 Node.js，打开 PowerShell 敲下 npm -v，结果没看到版本号，反而整屏红色：

code复制npm : 无法加载文件 C:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本。
有关详细信息，请参阅 https:/go.microsoft.com/fwlink/?LinkID=135170 中的 about_Execution_Policies。
所在位置 行:1 字符: 1

这个报错几乎每个 Windows 开发者在某个阶段都会撞上一次，特别是在新电脑、公司统一配发的机器，或者刚从 CMD 切换到 PowerShell 习惯的时候。它和 npm 本身没有半点关系，Node.js 装得好好的，问题出在 Windows PowerShell 的执行策略（ExecutionPolicy）把 Node.js 自动生成的 npm.ps1 脚本拦了下来。这篇就专门把这个问题讲透：为什么会这样，有哪些解决路径，各自的适用场景和风险是什么，以及改完仍然失效时该怎么排查。

适合谁看？被这个报错卡住的初学者、想在 PowerShell 里顺畅跑 npm/pnpm 的前端和后端开发、给团队统一配环境的运维，都可以按需取用。解决方案从临时绕过到永久修改都有，你只需要根据自己的安全要求挑一个。

1. 报错现场：npm -v 被 PowerShell 一票否决的真实情况

先还原一下完整链路，因为很多人不知道报错的触发条件根本不是"npm 坏了"。

你从 nodejs.org 下载 Windows 安装包，一路 Next 装完。此时系统里其实存在三个"npm"入口文件，都在 C:\Program Files\nodejs\（如果你改了安装路径，就在对应目录）：

• npm：无扩展名的 shell 脚本，给类 Unix 环境用的
• npm.cmd：批处理脚本，给 CMD 命令行用的
• npm.ps1：PowerShell 脚本，给 Windows PowerShell 用的

你在 CMD 里敲 npm -v，系统找到的是 npm.cmd，CMD 直接执行批处理，不经任何脚本策略审查。但在 PowerShell 里敲 npm -v，PowerShell 会优先找 npm.ps1，然后执行策略引擎开始检查这个脚本是否允许运行。

问题就出在这里：Windows 客户端的 PowerShell 默认执行策略是 Restricted，意思是"不加载任何配置文件，不运行任何脚本"。Node.js 安装程序不会帮你改这个策略，于是 npm.ps1 被整体拒绝，你看到的红色报错就是执行策略引擎抛出的拒绝信息。

同样的现象也会出现在：

• VS Code 内置终端默认走 PowerShell，所以很多人在 VS Code 里敲 npm 命令报错
• 安装了 pnpm、yarn 的机器，它们的入口脚本同样是 .ps1，会被一起拦
• 公司安全策略通过组策略把执行策略锁死为 Restricted 或 AllSigned 的机器，报错更顽固

另外，注意区分两种容易混淆的报错。如果你敲 npm -v 得到的是"npm 不是内部或外部命令"或"无法将 npm 项识别为 cmdlet 函数脚本文件"，那说明 nodejs 目录根本没在 PATH 环境变量里，那是另一个问题，跟执行策略无关。执行策略的报错永远指向"无法加载文件 npm.ps1"，关键字在 .ps1 和"禁止运行脚本"上。

提示：排查前先确认报错文字里有没有 npm.ps1。没有 npm.ps1 却报错，就别折腾执行策略了，先检查 PATH 环境变量。

2. 为什么PowerShell会拦住npm，CMD却一直相安无事

这一节把执行策略的机制拆开，理解了它，后面选方案就是顺手的事。

2.1 执行策略：PowerShell 的脚本安全闸门

PowerShell 的定位是系统管理 Shell，它不只是执行命令，还能运行任意 .ps1 脚本，这意味着一旦允许脚本运行，恶意脚本也就有了入口。所以微软设计了一整套策略分级，在运行脚本前先判断"这份脚本来自哪里、有没有签名、当前环境允不允许它跑"。

执行策略不是权限体系，它只是"允许/禁止"的开关组合。Windows 客户端（家庭版、专业版、企业版）的默认策略是 Restricted，服务器的默认策略通常是 RemoteSigned。这就是为什么很多在服务器上正常跑的脚本，换到个人电脑就报禁止运行。

2.2 五个策略作用域和它们的优先级

执行策略分为五个层级，从高到低：

系统做判断时，从高往低找第一个"不是 Undefined"的策略，直接采用，后面的全部忽略。这就是为什么有时你明明执行了 Set-ExecutionPolicy RemoteSigned，结果再查还是 Restricted——因为机器上有更高优先级的 MachinePolicy 或 UserPolicy 把设置锁死了。

2.3 策略值各自的含义

常用策略值有六个：

• Restricted：不运行任何脚本，只能交互式输入命令。Windows 客户端默认值
• RemoteSigned：本地创建的脚本可以运行；从互联网下载的脚本必须带可信数字签名
• AllSigned：所有脚本都必须签名，无论来源
• Unrestricted：所有脚本都可以运行，但运行未签名下载脚本前会提示
• Bypass：不拦截、不提示，所有脚本直接执行
• Undefined：未设置，会回退到下一优先级作用域

对开发者来说，RemoteSigned 是个人电脑上最平衡的选择：本机生成的脚本畅通无阻，外来的未签名脚本会被挡住，不至于裸奔。

2.4 为什么不是改一下 npm 就能解决

有朋友会想：我能不能给 npm.ps1 签个名，或者干脆删掉它？删掉 npm.ps1 确实可以让 PowerShell 找不到 .ps1 文件后回退到 npm.cmd，但 Node 安装目录属于 Program Files，普通用户改里面的文件本来就要管理员权限，而且以后 npm 升级、重新安装时文件会被恢复，不是一劳永逸的办法。给脚本签名又涉及证书，对个人开发者完全是多余的负担。

所以正确思路不是绕过 npm，而是调整 PowerShell 的执行策略，让合法的本机开发脚本可以运行。下面进入实操。

3. 五套解决方案：从临时绕过到一劳永逸

先说结论：个人开发机推荐用第 3.2 节的 RemoteSigned + CurrentUser，这是多数前端、Node 开发者默认的选择。但不同场景各有更合适的解法，我按"改动力度"从轻到重排列。

3.1 临时绕过：启动参数 -ExecutionPolicy Bypass

不改任何配置，只在当前 PowerShell 窗口里临时放开限制。适合偶尔用一次、不想动系统设置的人。

打开 PowerShell 时这样启动：

powershell复制powershell -ExecutionPolicy Bypass

或者直接在 CMD、任务管理器里用：

code复制powershell -ep bypass

执行后进入的是一个新的 PowerShell 进程，这个进程内执行策略临时变成 Bypass。你在里面敲 npm -v，会正常输出版本号。关闭窗口，一切回到原样。

还有一种更精准的临时方式，适合只跑一条命令：

powershell复制powershell -ExecutionPolicy Bypass -Command "npm -v"

这条会启动子进程执行 npm -v，执行完自动退出。

我的看法：这个方案只适合"应急"，不适合作为日常入口。因为每次都要带参数启动，很容易忘；而且 Bypass 意味着这个窗口里所有脚本都不设防，如果你还要执行下载来的其他脚本，风险敞口太大。真要长期在 PowerShell 里开 npm，还是用第 3.2 节。

3.2 推荐方案：Set-ExecutionPolicy RemoteSigned，只改当前用户

这是我认为开发机上"性价比"最高的方案，一句话就能永久解决，而且只对当前用户生效，不动系统全局策略。

以普通用户身份打开 PowerShell，执行：

powershell复制Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

系统会提示确认：

code复制执行策略更改
执行策略可帮助你防止执行不信任的脚本。更改执行策略可能会产生安全风险...
是否确实要更改执行策略?
[Y] 是(Y)  [A] 全是(A)  [N] 否(N)  [L] 否全部(L)  [S] 挂起(S)  [?] 帮助

输入 Y 回车。

验证是否生效：

powershell复制Get-ExecutionPolicy -Scope CurrentUser

输出应该是 RemoteSigned。此时再敲 npm -v，正常输出版本号。

几个细节：

• 不需要管理员权限。CurrentUser 作用域写的是当前用户注册表，无需提权
• 只影响当前用户，不影响这台机器上的其他用户，也不影响 CMD
• 如果公司电脑的域策略已经锁定了执行策略，这条命令可能会提示被策略覆盖，这种场景请看第 3.3 节
• RemoteSigned 对本地脚本和从网络下载的脚本区别对待，npm.ps1 是在安装 Node 时本地生成的，能直接跑，这点可以放心

3.3 组策略统一管控：公司机器、多用户环境

如果你在的公司用组策略统一管理电脑，或者你本人就是运维，需要给一批机器统一放开，那就不要逐个用户敲命令了，直接用本地组策略编辑器。

按下 Win + R，输入 gpedit.msc 回车。如果没有这个命令，说明系统是家庭版，组策略编辑器默认不装，仍然用第 3.2 节的方法即可。

进入后按路径展开：

code复制计算机配置 -> 管理模板 -> Windows 组件 -> Windows PowerShell

右侧找到"打开脚本执行"，双击打开：

• 选择"已启用"
• 在"执行策略"下拉框里选择"允许本地脚本和远程已签名脚本"，对应 RemoteSigned
• 如果想完全放开，选"允许所有脚本"

点击"确定"。之后在 PowerShell 里执行：

powershell复制gpupdate /force

让策略立即生效。

验证：

powershell复制Get-ExecutionPolicy -List

这时 MachinePolicy 一栏应该会显示 RemoteSigned，而不是原来的 Undefined。此时即使你在用户级把策略设成其他值，也会被这一条覆盖，这就是组策略优先级高的实际体现。

这个方案适合的场景：给团队统一开 Node 开发环境、在测试服务器上放行脚本、批量部署时在镜像里预设策略。缺点是策略是整个机器生效的，如果有同事只需要普通用户权限却被放开了脚本执行，安全上需要评估。

3.4 直接调用 npm.cmd：不改任何策略

如果你不想碰执行策略，但偶尔需要在 PowerShell 里跑 npm，可以直接调用 npm.cmd。npm.cmd 是批处理文件，不经过 PowerShell 执行策略检查。

在 PowerShell 里这样写：

powershell复制npm.cmd -v

或者把完整路径写出来：

powershell复制C:\Program Files\nodejs\npm.cmd -v

这条命令会正常输出 npm 的版本号。

也可以做一个别名，让日常使用更顺手。在当前 PowerShell 会话里临时加：

powershell复制Set-Alias -Name npmv -Value "C:\Program Files\nodejs\npm.cmd"
npmv -v

但要注意：别名只作用于当前会话，关掉就没了。想永久加，需要写 PowerShell Profile，维护成本比直接开执行策略更高。

还有一种变通做法：把默认终端改成 CMD。VS Code 里按 Ctrl + Shift + P，输入 Terminal: Select Default Profile，选择"命令提示符 cmd"，此后在 VS Code 终端里跑 npm 就不会碰到执行策略。这只是把问题从 PowerShell 身上挪开，对必须用 PowerShell 的场景依然无效。所以我把它定位为"应急方案"而不是"解决方案"。

3.5 注册表修改：无人值守和批量部署

如果给团队服务器装环境时不想跑交互式命令，或者需要把执行策略固化到镜像里，可以直接改注册表。

PowerShell 5.1 和 PowerShell 7 在 Windows 上读取的执行策略，本质上来自注册表。手动修改的位置：

当前用户：

code复制HKEY_CURRENT_USER\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell

本机所有用户：

code复制HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell

在这两个路径下新建字符串值 ExecutionPolicy，值设为 RemoteSigned。

用命令行设置等价效果，可以在部署脚本里用：

powershell复制Set-ItemProperty -Path "HKCU:\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell" -Name ExecutionPolicy -Value RemoteSigned

或者用 reg add：

code复制reg add "HKCU\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell" /v ExecutionPolicy /t REG_SZ /d RemoteSigned /f

改完之后同样用 Get-ExecutionPolicy 验证。

需要提醒的是，注册表方案在"执行策略被组策略锁死"的机器上同样无效，因为组策略写入的注册表项优先级更高，而且组策略引擎会在下次刷新时覆盖手工修改。所以注册表方案更适合全新安装、还没有域策略介入的机器。

4. 选哪个方案？安全性与便利性的实际权衡

前面给出五条路，每条路之间不只是"能不能解决问题"的差别，还有安全语义上的差异。我把它们放在一张表里对比，方便你按场景挑：

从安全和便利的平衡点来看，个人电脑上 RemoteSigned + CurrentUser 是最优解。它保留了"网络下载的未签名脚本被拦截"这道防火墙，同时放行本机安装工具生成的脚本。Node.js、Visual Studio、Git 等开发工具生成的 .ps1 都属于本地脚本，能正常运行。

有人会想，干脆 Set-ExecutionPolicy Bypass -Scope CurrentUser，一劳永逸，什么都不拦。短期内确实没感觉，但等你哪天手滑下载并执行了一个未签名的恶意 .ps1，后悔就来不及了。Bypass 连提示都不弹，是给临时场景设计的，不应该成为日常配置。

AllSigned 比 RemoteSigned 更严格，要求所有脚本都必须有数字签名，包括本地的。这会导致 Node 的 npm.ps1 也跑不了，除非你给所有工具脚本都签一遍名——开发机上没必要自找这种麻烦，它更适合严格安全管控的服务器环境。

还有一点，Unrestricted 虽然允许所有脚本运行，但对于从网络下载的未签名脚本会在运行时弹窗询问。弹窗在自动化场景里非常讨厌，所以开发机上也不推荐。

我的建议很简单：个人开发机，用 RemoteSigned + CurrentUser；公司统一管理，让运维在组策略里按模板开 RemoteSigned；临时救急，才用 Bypass 或 npm.cmd。

5. 改完还不生效？连带问题排查链路

前面所有方案执行完，一般敲 npm -v 就出结果了。但总有些机器改完仍然报错，或者从"执行策略报错"变成"另一个报错"，这时候按下面的链路排查，基本能定位。

5.1 排查顺序：从执行策略本身开始

先在 PowerShell 里执行：

powershell复制Get-ExecutionPolicy -List

看输出：

code复制Scope          ExecutionPolicy
-----          ---------------
MachinePolicy  Undefined
UserPolicy     Undefined
Process        Undefined
CurrentUser    RemoteSigned
LocalMachine   Undefined

如果 CurrentUser 是 RemoteSigned，而 MachinePolicy 或 UserPolicy 里出现非 Undefined 的值，说明策略是被更高层覆盖的。此时你在会话里执行 Set-ExecutionPolicy 往往会报"因安全策略被覆盖"之类的错误。

在这种被钳制的环境下，普通用户无法突破高层策略，只能：

• 找管理员调整组策略，把执行策略改为允许本地脚本
• 如果只是临时需要，用带 -ExecutionPolicy Bypass 参数启动的进程（Process 作用域优先于 CurrentUser，但低于 MachinePolicy，所以如果 MachinePolicy 被锁成 Restricted，Bypass 也救不了你）

5.2 注意区分另一个高频报错：npm 不是内部或外部命令

执行策略报错解决后，紧接着可能出现的是：

code复制npm 不是内部或外部命令，也不是可运行的程序或批处理文件。

或者 PowerShell 版：

code复制无法将“npm”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。

这个报错和脚本执行策略无关，是 PATH 环境变量里没有 nodejs 的安装目录。用以下命令当场验证：

powershell复制Get-Command npm -ErrorAction SilentlyContinue
where.exe npm

如果没有输出，说明 PATH 缺失。去"系统属性 -> 环境变量"里把 C:\Program Files\nodejs\ 加到 Path 里，然后重开终端。

需要注意的是：改完 PATH 必须重开 PowerShell 窗口才生效，VS Code 终端也要重开。很多人改完环境变量发现还是不起作用，就是因为终端会话缓存了旧的 PATH。

5.3 连带工具：pnpm 和 cnpm 也会遇到同款问题

如果你之前装过 pnpm、yarn、cnpm，那么执行策略改了之后它们也会一并恢复正常，因为它们的入口机制和 npm 一样，都包含 .ps1 脚本。理论上不需要对每个工具单独处理。

但如果你的 pnpm 是用 npm 全局安装的，而安装时用的是 CMD，之后在 PowerShell 里跑 pnpm -v 同样会撞上 .ps1 报错，和 npm 的解法一模一样——RemoteSigned 一开，全好了。

补充一个内网场景：公司电脑在内网开发，解压 node_modules 后看到依赖目录名都带下划线前缀，然后 npm run dev 报错。这个和本章主题相关但不是同一类问题，下划线前缀通常是 npm 缓存目录或node_modules/.store（pnpm 的产物）造成的混淆，执行策略改完才能继续排查这类问题，但别把所有问题都归到执行策略头上。

5.4 其他偶发性连带问题

• 修改策略后提示"未授权访问注册表"：用 CurrentUser 作用域时不该出现，如果出现，可能是杀毒软件或安全软件拦截了注册表写入，检查安全软件日志
• 运行 Set-ExecutionPolicy 时报"由于未在此系统上启用脚本执行，无法加载配置文件"：你的 PowerShell Profile 里可能写了自定义脚本，Profile 本身也被策略拦着，先处理策略，再重开终端
• PowerShell 7（pwsh）和 Windows PowerShell 5.1 并存时，策略是共享注册表存储的，但如果你给 pwsh 单独做了 -Scope Process 设置，那是独立于 5.1 的，别混为一谈
• 修改完成后 npm 命令能跑，但某些脚本工具（比如自定义 .ps1）仍然被拦：检查脚本是否来自网络下载，RemoteSigned 会要求远程脚本带签名，这个行为是设计使然

6. 避坑经验：执行策略背后的那些细节

最后聊几个踩过坑之后才真正理解的点。

6.1 执行策略不等于权限，别被名字误导

它只是"允不允许脚本跑"的开关，跟"你能不能在系统里做管理员操作"是两回事。一台机器的执行策略就算设成 Bypass，普通用户依然不能随意改系统目录、装驱动、改服务。所以别把 Restricted 当成了防恶意软件的防火墙，真正的防线是杀毒软件、SmartScreen 和用户自己的判断。

6.2 Node.js 升级不会改掉你的执行策略

你以后从 Node 18 升级到 Node 20、22，执行策略依然是你设过的 RemoteSigned，不需要重新设置。因为这个策略是 PowerShell 自己的状态，存在注册表里，跟 Node 无强绑定。反过来，如果你重装系统、换电脑，新的机器上仍然要重新设置一遍，没有自动迁移这回事。

6.3 远程下载脚本的签名规则

RemoteSigned 判断"远程脚本"靠的是文件流上的标记（Zone.Identifier），不是看文件的存放位置。你从浏览器下载一个 .ps1 到本地，再把它复制到 D 盘，它依然会被识别为"来自远程"，没有签名就拒绝运行。开发时常常遇到"我自己的脚本怎么也被拦"的困惑，原因多半就是脚本是从网上下载的。解除这种标记可以用：

powershell复制Unblock-File -Path .\your-script.ps1

或者用属性面板里的"解除锁定"勾选。这在处理团队共享脚本时特别有用。

6.4 给团队一台机器做批量配置时的顺滑流程

如果要快速在新机器上配置 Node 开发环境，我习惯用一行命令完成"检查现状 + 设置策略 + 验证"：

powershell复制Get-ExecutionPolicy -List; Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force; Get-ExecutionPolicy -Scope CurrentUser

加 -Force 参数可以跳过确认提示，适合写进初始化脚本。

6.5 真正的安全底线

聊到最后还是要提醒一句：执行策略放开了，你就有了运行任意 .ps1 的可能。日常开发中尽量只运行来源可靠的脚本，别随便从论坛、群里复制一段 .ps1 就执行。RemoteSigned 能挡住一部分未签名脚本，但签名脚本不一定是安全的，一个签名证书只代表"签名者是谁"，不代表"脚本没有恶意行为"。保持对脚本来源的基本判断力，比任何策略设置都重要。

我在实际配置中还有一个小习惯：设置完执行策略后马上重开一次 PowerShell 窗口，避免当前会话残留旧的策略缓存，也让后续的 npm 运行环境更干净。这不算什么高深技巧，但确实省掉过不少"明明改了却不生效"的疑惑。希望这篇能把你的 npm -v 从红色报错里救出来，也让你对 Windows 脚本执行机制有个清晰的认识。