1. 先别急着搜命令：这个报错的真实意思是PowerShell不让你跑脚本
我记得很清楚，第一次在自己电脑上装完Node.js，兴冲冲打开PowerShell，输入npm -v，结果屏幕上砸下来一串红字：
npm : 无法加载文件 D:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本。 有关详细信息，请参阅 https://go.microsoft.com/fwlink/?LinkID=135170 中的 about_Execution_Policies。当时第一反应是"是不是Node.js没装好？是不是环境变量配错了？"，又去翻PATH、又重装了一遍Node.js，折腾半天还是老样子。后来才明白，这个报错跟Node.js一毛钱关系都没有，是Windows PowerShell的**执行策略（Execution Policy）**在拦截。
简单说，PowerShell默认的Restricted策略下，禁止运行任何.ps1脚本文件。而npm在Windows上有一个官方提供的PowerShell启动脚本npm.ps1，你每次在PowerShell里敲npm，实际执行的就是这个脚本文件。系统策略不让你跑脚本，于是npm就被拦在了门外。
这个错误在国内开发者里出现频率极高，尤其是在学校机房、公司预装机和新买的个人电脑上。原因很简单：大多数人装Node.js时的默认终端就是PowerShell，而Windows对PowerShell脚本的限制是出厂自带的默认设定，不是我们手动配置出来的。
网上搜这个报错，能搜出一大堆五花八门的"修复命令"，什么Set-ExecutionPolicy RemoteSigned、Set-ExecutionPolicy Unrestricted，还有改注册表的。有些管用，有些半吊子，有些改了之后安全软件直接报警。这篇文章我从原理到实操，把这个问题一次讲透，顺便把所有连带坑都给你排干净，适合刚接触Node.js的新手，也适合被这个报错反复折腾过的老手。
2. npm在Windows上其实有三个启动文件：搞懂它们才能理解为什么会触发执行策略
2.1 npm、npm.cmd、npm.ps1三兄弟的分工
很多人不知道，你安装完Node.js之后，在nodejs安装目录下（比如D:\Program Files\nodejs\）能看到三个跟npm相关的可执行文件：
npm：无扩展名，实际是一个Shell脚本，主要给类Unix环境（Linux、macOS、Git Bash等）使用。npm.cmd：Windows的命令行脚本，给CMD（命令提示符）使用。npm.ps1：Windows PowerShell脚本，给PowerShell使用。
你在CMD里输入npm，系统找到的是npm.cmd；在PowerShell里输入npm，系统找到的是npm.ps1。问题就出在，npm.ps1这个文件会被PowerShell的执行策略拦截。
这也是为什么很多人的第一反应是"我的npm不是装好了吗"，因为在CMD里试一下npm -v，往往又能正常输出版本号。同一个工具，换个终端结果完全不同，这就会让人误以为是环境变量路径配错了，其实只是PowerShell的脚本策略在起作用。
2.2 官方为什么要提供.ps1脚本
这里有个值得说一嘴的背景：PowerShell是微软为了取代传统CMD推出的新一代命令行环境，它的执行策略从设计之初就偏向"安全优先"。微软默认在Windows系统上禁用了.ps1脚本的执行能力，目的是防止恶意脚本随便在用户的Shell里跑。这个设计本身没有问题，问题在于它同时误伤了npm这样完全正当的开发者工具。
另外，Node.js官方在Windows上提供.ps1脚本，是为了让PowerShell用户能拿到和CMD用户一致的命令体验。没有它的话，你在PowerShell里可能就需要手动输入npm.cmd才能执行。结果就是，官方做了贴心设计，Windows的安全机制又把这个贴心设计给拦住了，最终受害的是我们这群躺在中间的普通开发者。
2.3 为什么Git Bash和WebStorm终端里不报错
这个问题我被问过很多次："为什么我在VSCode的终端里报错，在WebStorm里就没事？"或者"为什么我打开Git Bash敲npm就正常？"
原因就是不同的终端环境调用的启动文件不一样：
- Git Bash基于Unix工具集，它执行的时候找的是无扩展名的
npmShell脚本，不经过PowerShell执行策略，所以不会报错。 - WebStorm内置终端在Windows上默认使用的是
cmd.exe（或者你手动改成PowerShell），用CMD当然走的是npm.cmd，同样不触发策略。 - VSCode的默认终端通常继承系统默认设置，很多人用的恰好就是PowerShell，于是一报一个准。
所以你会发现，同样一条npm -v命令，换个Shell就活，再换回PowerShell就死。这个现象跟版本无关，跟环境变量无关，纯粹是终端类型的差异。
3. 修复方案全景：按使用场景和风险等级逐个拆解
3.1 方案一：临时给当前PowerShell窗口放开限制
如果你只是临时用一下npm，不想对系统做任何修改，最轻量的办法是只修改当前PowerShell进程的执行策略：
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass这条命令的意思是：只对"当前这个PowerShell窗口"放开限制，窗口一关，设置就失效，下次打开新窗口，策略恢复原样。
-Scope Process是影响范围最小的级别，不需要管理员权限，不需要改注册表，也不会改动系统全局配置。它相当于你对这个终端窗口说："这次我不检查了，你放行吧。"
这个方案适合什么人呢？比如你在公司电脑上，没有管理员权限，改不了系统级设置，又确实需要在PowerShell里跑npm，那一句命令下去就能用了。缺点也很明显，你每次新开窗口都要重新执行一次，治标不治本。
3.2 方案二：修改当前用户级执行策略（我最推荐的方案）
如果你想在个人电脑上彻底解决这个问题，又不想以管理员身份操作，那么设置当前用户级别的执行策略是性价比最高的方案：
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned执行之后，系统会弹出一个确认提示，问你是否要更改执行策略，输入Y回车即可。
RemoteSigned的含义是：本地创建的脚本允许运行，从互联网下载的脚本必须有受信任发布者的数字签名才能运行。这个策略既解决了npm.ps1的拦截问题，又保留了对网上下载脚本的审查能力，比直接改成Unrestricted（无限制）要稳妥得多。
我为什么推荐这个方案？三点理由：
- 作用范围只有当前用户，不碰系统级配置，权限粒度合适；
- 不需要管理员权限，普通用户账户就能执行；
RemoteSigned作为执行策略，安全性和便利性的平衡点刚刚好，不会像Unrestricted那样让安全软件疯狂报警。
执行完后，可以把PowerShell窗口关掉重开，或者直接输入Get-ExecutionPolicy查看当前策略值，确认输出是RemoteSigned，再去跑npm -v，这时候就不会再报错了。
3.3 方案三：管理员身份修改本地机器策略
如果你的电脑上存在多个用户账户，希望所有用户都能跑PowerShell脚本，那就需要管理员权限去修改本地机器级别的执行策略：
Set-ExecutionPolicy -Scope LocalMachine -ExecutionPolicy RemoteSigned注意，这一步必须用"以管理员身份运行"的方式打开PowerShell，否则会提示拒绝访问或权限不足。
我在实际中踩过的一个坑是：很多教程写了Set-ExecutionPolicy RemoteSigned，没写-Scope参数。默认的-Scope就是LocalMachine，对当前用户不生效的情况很少见，但如果你正好处于"当前用户策略被组策略覆盖"的环境（比如公司域环境），那这条命令执行后可能依然无效。判断标准是你输入Get-ExecutionPolicy -List，查看各级策略的具体生效值。
这种改动方式的麻烦之处在于：它把影响范围扩大到了整台机器上所有用户的所有PowerShell会话。如果你只是自己开发用，完全没必要动这一级，方案二就够了。
3.4 方案四：不修改策略，用绕过参数跑单条命令
有些场景下，你既不想改变执行策略的默认值，又需要跑npm，比如在一个测试环境或者临时用的机器上。这时候PowerShell提供了一个一次性绕过参数：
powershell -ExecutionPolicy Bypass -Command "npm -v"这个方式的思路是：启动一个全新的PowerShell子进程，在这个子进程的执行策略直接设为Bypass（完全跳过），然后把你要执行的命令当作参数传进去。命令跑完，子进程退出，对系统没有任何残留影响。
不过这种方式日常开发用起来很别扭，因为每次都要写一大长串命令。它更适合放在脚本或批处理文件里做自动化时用，比如你写了一个.bat文件需要临时调用PowerShell跑某个npm脚本，又不想动全局策略，就可以这么干。
3.5 四种方案对比
为了让你一眼选对，我把这几种方案的适用场景和风险做了个对照：
| 方案 | 命令 | 是否需管理员 | 影响范围 | 重启后是否失效 | 适用场景 |
|---|---|---|---|---|---|
| 临时放开 | Set-ExecutionPolicy -Scope Process Bypass | 否 | 当前窗口 | 是 | 临时跑一下、没有管理员权限 |
| 当前用户级 | Set-ExecutionPolicy -Scope CurrentUser RemoteSigned | 否 | 当前用户 | 否 | 个人开发机、首选方案 |
| 本地机器级 | Set-ExecutionPolicy -Scope LocalMachine RemoteSigned | 是 | 所有用户 | 否 | 多用户共用一台机器 |
| 单次绕过 | powershell -ExecutionPolicy Bypass -Command "npm -v" | 否 | 单条命令 | 是 | 自动化脚本、临时调用 |
表中提到的"重启后是否失效"，指的是PowerShell窗口重新打开之后，这个执行策略的修改还不在。方案一和方案四的新窗口打开后策略会恢复原样，方案二和方案三会一直保留在注册表对应位置。
4. 改完了还报错？几个高频连带问题一次排查干净
4.1 修改策略后仍然提示禁止运行脚本
这是评论区里出现频率最高的追问："我明明执行了Set-ExecutionPolicy RemoteSigned，也显示成功了，为什么再跑npm还是同样的报错？"
我一般建议按下面三步排查：
- 确认当前窗口是否重开。如果你修改完策略没有关掉当前PowerShell窗口，执行策略的变更可能没有完全生效到当前会话，建议直接关掉终端重新打开一个再试。
- 用
Get-ExecutionPolicy -List查看各级别策略的最总效果。PowerShell的执行策略是分层生效的，LocalMachine、CurrentUser、Process三个级别同时存在，最终生效的规则遵循就近原则，Process优先于CurrentUser，CurrentUser优先于LocalMachine。如果你在某个级别设置了Restricted、Undefined或AllSigned，可能会覆盖你已经改好的RemoteSigned。这里有个容易被忽略的知识点：如果上一级策略是Undefined，那就会落到下一级去判断，如果全部都是Undefined，才用系统默认值Restricted。 - 检查组策略是否强覆盖。在公司的域环境里，IT部门可能通过组策略（GPO）锁定了执行策略，这种情况下你在命令行里改的权限是无效的，
Get-ExecutionPolicy -List会看到组策略对应的那一级显示为RemoteSigned等值，且无法通过命令行变更。解决办法只能联系管理员，或者用方案一跳过策略。
4.2 VSCode的终端类型导致时而正常时而不正常
很多人修好之后，发现PowerShell里跑npm一切正常，但在VSCode的终端里还是报错，或者反过来。这通常不是执行策略的问题重复出现，而是VSCode默认终端被设置成了PowerShell，但是VSCode内部启动的PowerShell继承的上下文跟你手动打开的不完全一致。
最简单的排查方法是：在VSCode里按Ctrl + Shift + P，输入Terminal: Select Default Profile，看看当前选择的是PowerShell还是CMD，还是Git Bash。如果是PowerShell且执行策略正常，那问题一般出在VSCode的环境变量加载顺序上——你修改执行策略用的PowerShell和你VSCode里打开的那个，可能从不同的注册表路径加载了配置。
更省事的做法是：直接把VSCode默认终端切换到Command Prompt或Git Bash。因为npm在这两种终端里走的是npm.cmd或无扩展名脚本，不依赖PowerShell执行策略，绕开了这整个问题。
4.3 nvm、nrm等工具的脚本同样受执行策略影响
修复npm.ps1之后，你可能会陆续装上一些Node.js生态里的命令行工具，比如版本管理工具nvm-windows、npm镜像源管理工具nrm，它们同样会提供.ps1启动脚本，照样会被PowerShell拦截。
这不是新问题，而是同一个执行策略问题的延伸。好消息是你已经修好了CurrentUser级别的策略，这些工具和npm一样属于本地脚本，RemoteSigned对本地创建的脚本不拦截，所以都能正常使用。如果你当初用的是临时放开的方案，那每次新装的工具一旦换了新窗口，还会继续报同样的错。
所以我的建议是：既然要修，就一步到位改成CurrentUser + RemoteSigned，别用临时方案糊弄自己，不然之后每装一个工具都可能踩一遍雷。
4.4 用CMD和Git Bash作为长期替代方案
如果出于种种原因，你不想改PowerShell的任何策略（比如公司电脑上有严格的安全规范），还有一个舒舒服服的办法：直接换终端。
- CMD：系统自带，按
Win + R输入cmd回车，在CMD里运行npm -v、npm install、npm run build等命令，走的是npm.cmd，完全不受执行策略影响。 - Git Bash：安装Git for Windows时自带，如果你平时已经装了Git，直接在开始菜单打开
Git Bash，里面走的是Shell脚本路径，也完全没问题。 - Windows Terminal：如果安装了这个终端软件，可以同时配置CMD、PowerShell、Git Bash多个配置文件，切来切去很方便。
这里分享一个小技巧：在CMD里跑完npm命令后，按上箭头可以调出历史命令，方向键左移可以修改命令，熟悉Windows传统终端操作的人用起来很顺手，不会因为环境换了而影响开发效率。
5. 从根上理解执行策略：四个级别和五个取值分别代表什么
5.1 四个作用范围级别
PowerShell执行策略有四个作用范围，从窄到宽依次是：
| 范围 | 含义 | 修改方式 |
|---|---|---|
Process | 仅对当前PowerShell进程生效 | 不需要管理员权限 |
CurrentUser | 对当前用户的所有PowerShell会话生效 | 不需要管理员权限 |
LocalMachine | 对电脑上所有用户的所有PowerShell会话生效 | 需要管理员权限 |
| 组策略（GPO） | 由系统管理员通过组策略强制设定 | 命令行无法覆盖 |
这四个级别不是互斥的，而是叠加生效。系统判断时从最窄的范围开始，如果某一层策略不是Undefined，就按这一层执行；如果当前范围是Undefined，就继续往下一层找。
5.2 五个常见的策略取值
ExecutionPolicy的取值里，你会遇到的主要有五个：
Restricted：禁止任何.ps1脚本运行，Windows默认值。RemoteSigned：本地脚本和本地文件可以运行，从互联网下载的脚本需要数字签名。这是开发场景下最推荐的设置。AllSigned：所有脚本都必须有受信任的签名才能运行，本地自己写的不签名也跑不了。Unrestricted：所有脚本都能运行，安全性最低。Bypass：完全不检查，比Unrestricted还彻底，直接跳过执行策略判断。
你可能搜到过一条建议改Unrestricted的教程，我明确不建议照做。Unrestricted和Bypass会关闭PowerShell几乎所有脚本安全检查，在个人电脑上确实能一劳永逸，但代价是一旦某个恶意脚本混进你的终端环境，它会畅通无阻地执行。做开发本身就会下载大量依赖、跑各种开源工具，安全边界能留一道是一道，改成RemoteSigned足够用了。
5.3 一个误操作要留神：-Scope忘写导致越级修改
网上很多教程只写一句话Set-ExecutionPolicy RemoteSigned，没有-Scope。如果你是在管理员身份的PowerShell里执行，默认作用范围是LocalMachine，会改动整台机器的策略；如果不是管理员身份，则会报错"拒绝访问"。
我在帮别人排查问题时遇到过一种情况：有人先用管理员窗口执行了Set-ExecutionPolicy Unrestricted，后面又觉得不安全，再以普通用户窗口执行Set-ExecutionPolicy Restricted，结果因为作用范围不同，系统实际生效的策略依然是LocalMachine = Unrestricted，用户评估了整个机器的安全性。这就是没有理解作用范围层次导致的操作混乱。
所以无论执行什么命令，都建议带着-Scope参数，明确告诉PowerShell你要改动哪一级，避免误改更高权限级别的配置。
6. 两个日常实用技巧：改完策略之后值得顺手做的事
6.1 用Get-ExecutionPolicy确认修改结果
修改策略的当下，我会立即执行下面命令确认：
Get-ExecutionPolicy -List # 输出示例 # Scope ExecutionPolicy # ----- --------------- # MachinePolicy Undefined # UserPolicy Undefined # Process Undefined # CurrentUser RemoteSigned # LocalMachine Undefined看到CurrentUser一栏是RemoteSigned，就说明改到位了。每次都确认一下，省得改了半天发现改错了层级，再来回折腾。
6.2 给PowerShell配置一个快速检查npm环境的小脚本
既然执行策略已经放开了，你还可以利用PowerShell写点自己的辅助函数。比如在$PROFILE文件里加一个函数，新开终端自动检查Node.js和npm的版本，以及当前镜像源：
function Show-NodeEnv { Write-Host "Node.js version: $(node -v)" Write-Host "npm version: $(npm -v)" Write-Host "npm registry: $(npm config get registry)" }然后直接输入Show-NodeEnv就能一眼看清当前开发环境的状态。这个动作很小，但在日常切换项目、排查环境问题时非常省心。
需要注意，$PROFILE文件对应的路径可能不存在，第一次写之前需要先执行New-Item -Path $PROFILE -Type File -Force创建。如果你不想折腾这些，完全可以跳过，这只是锦上添花的小技巧。
根据我个人这几年在新机器、公司电脑、虚拟机里反复折腾这个报错的经验，最稳的一套流程就是：普通个人电脑上用CurrentUser级别把执行策略改成RemoteSigned，然后重新打开PowerShell窗口，这个问题基本就跟你永别了。如果后续在VSCode或者其他终端里又遇到类似的"禁止运行脚本"报错，先看一眼那个终端用的是不是PowerShell，再想想自己有没有在别的窗口改过策略，这两点能解决九成的问题。
