终端里跑个脚本，结果PowerShell甩回来一句"因为在此系统上禁止运行脚本"，后面还跟着一个微软的帮助链接。这个场景对开发者来说太熟悉了，尤其是刚接触Node.js、Python或者任何需要跑.ps1脚本的朋友，十有八九都被这个报错堵过路。今天我把这个问题的来龙去脉、底层机制和所有能用的解决办法一次性讲清楚，保证你看完能自己动手解决，下次遇到同类问题也不会慌。

先说说这个报错到底是什么。简单来说，Windows PowerShell默认的脚本执行策略是Restricted（受限），这个策略下系统不允许运行任何.ps1脚本文件。你敲一条命令没问题，但你一旦尝试运行一个写好的.ps1脚本，系统就会立刻拦截，并抛出这个"禁止运行脚本"的错误。它本质上是一道安全门槛，而不是系统出了故障——理解了这一点，你就能明白后面所有解决方案都是在"如何合理地打开这扇门"上做文章。这篇文章适合所有在Windows终端遇到脚本执行报错的人，无论是做前端开发、运维、自动化还是学习PowerShell的老哥，看完都能直接照着操作。

1. 项目背景与报错场景还原

1.1 这个报错长什么样

我先还原一下现场。最常见的报错就是你在终端里执行类似这样的命令：

npm install

或者：

.\deploy.ps1

然后PowerShell直接给你弹出一段红色的错误信息：

无法加载文件 D:\nodejs\npm.ps1，因为在此系统上禁止运行脚本。有关详细信息，请参阅 https:/go.microsoft.com/fwlink/?LinkID=135170 中的 about_Execution_Policies。

注意看，这个错误信息分两部分。前半句"无法加载文件...禁止运行脚本"告诉你被拦截的目标是谁，后半句给了一个帮助文档的链接，指向PowerShell官方的about_Execution_Policies主题。这里有个细节很多人没注意：链接中的"https:/go.microsoft.com"少了一个斜杠，这个是PowerShell内置帮助文档的固定写法，不是笔误，复制到浏览器里也能正常跳转。

网上随手一搜，类似"npm : 无法加载文件 d:\node\npm.ps1"、"因为在此系统上禁止运行脚本"这类关键字的热度一直很高，说明这个坑真的有大量人踩过。尤其在国内开发者的环境里，很多人用的是Windows系统，装了Node.js之后，npm、npx这些命令本质上是调用了PowerShell的.ps1包装脚本，一旦执行策略是Restricted，所有基于npm的命令都会全军覆没。

1.2 为什么Windows要默认禁止脚本运行

这个问题的根源在于Windows系统对脚本安全的态度。早在PowerShell 1.0时代，微软就把执行策略设计成了一个安全边界，目的是防止用户在不知情的情况下运行恶意脚本。想象一下，如果系统允许任意.ps1脚本直接执行，那攻击者只要诱导用户下载一个脚本文件并双击运行，就能在用户权限范围内做任何事——删文件、装后门、窃取信息，全都可能发生。所以Windows默认采用Restricted策略，等于把"运行脚本"这扇门先锁上，让用户必须经过思考再决定要不要开门。

这在设计上很合理，但对开发者和运维人员来说却经常变成障碍。因为我们在日常工作中有大量合理、安全、可信的脚本需要运行，比如包管理器的包装脚本、自动化部署脚本、环境初始化脚本等。默认策略一刀切，把合理的请求也挡住了。这也解释了为什么"禁止运行脚本"和"PowerShell执行策略"这两个话题在开发者社区里被反复讨论——它其实是Windows安全模型与开发者效率需求之间的一个经典冲突点。

理解了这层背景，你就不会觉得这个报错是什么棘手的技术难题了。它就是一个执行策略配置问题，调整策略到合适的等级就能解决。关键不在于"怎么改"，而在于"怎么改得聪明、改得安全"。

2. 执行策略机制深度拆解

2.1 六种执行策略等级

PowerShell执行策略一共分六个等级，从最严格到最宽松分别是Restricted、AllSigned、RemoteSigned、Unrestricted、Bypass、Undefined。每个等级对脚本的放行程度不同，搞清楚它们的区别才能选对。

Restricted（受限）：这是Windows默认的策略。用户可以执行单个命令，但不能运行任何.ps1脚本文件。前面提到的报错就是这个等级下产生的。

AllSigned（全部签名）：所有.ps1脚本必须经过受信任的发布者数字签名才能运行。这个策略下，你自己写的本地脚本如果没有签名，同样会被拦截。适合对安全性要求极高的企业环境。

RemoteSigned（远程签名）：这是开发者和运维最常用的策略。本地创建的脚本可以直接运行，从互联网下载的脚本必须有受信任的发布者签名。换句话说，你自己写的、放在本地的脚本能跑，从网上下载的、标记了"来自网络"的脚本会被检查签名。

Unrestricted（不受限制）：所有脚本都可以运行，但从互联网下载的脚本运行时会有安全提示。这个策略适合对安全性要求不太高、但需要频繁运行各种来源脚本的人员。

Bypass（绕过）：不检查任何限制，所有脚本都能运行，也不会有提示。注意，Bypass并不是一个"策略等级"那么简单——它更像是一个临时开关，开发调试时为了方便可以临时用，但不建议作为长期策略。

Undefined（未定义）：代表未设置策略，此时会继承上一级作用域的策略，如果所有作用域都是Undefined，则默认按Restricted处理。

我用一个表格来对比这几个等级：

这个表里RemoteSigned是应用最广泛的，我自己的开发环境就长期用它。

2.2 作用范围与优先级

执行策略不仅有好几个等级，还分好几个作用范围。这也是很多新手容易搞懵的地方——你在命令行里敲了一个Set-ExecutionPolicy命令，提示修改成功了，但依然报错，往往就是作用范围没搞对。

PowerShell执行策略的作用范围有四个层级：MachinePolicy（机器策略）、UserPolicy（用户策略）、Process（进程）、CurrentUser（当前用户）、LocalMachine（本机）。它们的优先级从高到低依次是MachinePolicy > UserPolicy > Process > CurrentUser > LocalMachine。

• MachinePolicy和UserPolicy：通常由组策略（GPO）配置，在企业域环境中管理员会强制设定，普通用户无法修改。
• Process：只对当前PowerShell进程生效，关闭这个终端窗口就失效。适合这次运行脚本临时改一下，不影响系统其他部分。
• CurrentUser：只对当前用户生效，写到当前用户的注册表配置里。这个范围最推荐普通开发者使用。
• LocalMachine：对整个机器的所有用户生效，需要管理员权限才能修改。修改它会影响到机器上所有用户，风险更大。

优先级的设计逻辑是：更高级别的策略一旦设置，低级别的设置就不会生效。这就像公司制度一样，部门内部可以有自己的规矩，但公司级别有统一规定时，以公司的为准。所以，如果你在企业域环境里，组策略已经把执行策略锁成了AllSigned，那你在当前用户级别怎么改都是没用的。

2.3 如何查询当前策略

了解机制之后，第一步应该是先检查自己电脑上当前的执行策略是什么。在PowerShell里执行：

Get-ExecutionPolicy -List

这个命令会列出所有作用域当前的策略状态，输出格式很像这样：

Scope ExecutionPolicy ----- --------------- MachinePolicy Undefined UserPolicy Undefined Process Undefined CurrentUser Undefined LocalMachine Restricted

看到LocalMachine是Restricted，基本就定位到问题了——这就是默认配置导致的。如果你之前已经改过局部作用域，这里也能看到具体是哪个范围设置了什么策略，方便排查。

还有一个查询命令：

Get-ExecutionPolicy

不带参数的Get-ExecutionPolicy会返回当前生效的策略，也就是按优先级最高那个作用域的实际结果。这个命令适合快速判断当前环境到底能不能跑脚本。

3. 完整解决方案与实操

3.1 方法一：Set-ExecutionPolicy修改策略

最直接、也最通用的办法，就是用Set-ExecutionPolicy命令修改执行策略。打开PowerShell，执行：

Set-ExecutionPolicy RemoteSigned

注意，这个命令默认修改的是LocalMachine范围，需要管理员权限。所以你的PowerShell窗口必须以管理员身份运行。操作方法是右键点击开始菜单里的"Windows PowerShell"或"终端"，选择"以管理员身份运行"。

执行后系统会弹出一个确认提示，显示更改后的策略以及影响范围，输入Y确认就行。修改完跑一下：

Get-ExecutionPolicy

如果返回RemoteSigned，就说明策略已经修改生效。这时候你再运行之前的脚本，不管是npm还是.ps1文件，都能正常执行了。

这里有个坑：如果PowerShell不是以管理员身份运行，执行Set-ExecutionPolicy会直接报错，提示"拒绝访问"或者"因为系统上启用脚本执行策略而无法加载配置文件"。所以第一步务必确认终端窗口标题栏有"管理员"三个字，或者在用户账户控制弹窗里点了"是"。

3.2 方法二：Bypass策略绕过

有些场景下，你不想改动系统级别的执行策略，只是临时跑一个脚本。这种情况下，Bypass策略是最省事的。Bypass的语义是"跳过所有检查"，连签名和提示都不看，直接把脚本跑起来。

临时绕过的第一种方式是命令参数：

powershell -ExecutionPolicy Bypass -File .\deploy.ps1

这条命令会启动一个新的PowerShell进程，在这个进程内用Bypass策略来执行指定的脚本文件。注意，它不会修改任何作用域的持久化配置，关掉这个进程就恢复原样。这就是所谓的"临时放行"。

临时绕过的第二种方式是在PowerShell会话内临时修改Process作用域：

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

执行完这一句，当前PowerShell窗口立即获得Bypass权限，可以运行任意脚本。但只要关闭这个窗口，下次打开终端依然是原来的策略。这种方式的优点是只影响当前窗口，不影响系统其他程序，安全性相对可控。

我个人在调试一些来路不明的脚本时经常用Bypass方式，跑完就关，不污染系统环境。

3.3 方法三：只修改当前用户作用域

如果你不想用管理员权限，也不想影响本机其他用户，最推荐的方案是指定CurrentUser范围修改策略。在普通权限的PowerShell窗口里执行：

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

这条命令只需要当前用户权限就能完成，它会把策略写入当前用户的注册表配置文件中，不影响系统其他用户。对大多数开发者来说，这是最平衡的选择——既解决了脚本执行问题，又不影响系统全局安全设置。

执行后同样会有一个确认提示，输入Y确认。然后验证：

Get-ExecutionPolicy -Scope CurrentUser

返回RemoteSigned就搞定了。之后你在这个用户名下打开的所有PowerShell窗口都会继承这个策略。

这个方案有个优势是很容易恢复。如果哪天你不想让脚本自动运行了，再执行一遍这个命令，把RemoteSigned改成Restricted或者Undefined，就能把改动回滚掉。

3.4 方法四：组策略与注册表进阶控制

对于企业环境或者需要精细管理执行策略的场景，可以通过组策略编辑器来设置。在运行框输入gpedit.msc打开本地组策略编辑器，然后依次定位到"计算机配置 -> 管理模板 -> Windows 组件 -> Windows PowerShell"，在右侧找到"打开脚本执行"策略。

双击这个策略，选择"已启用"，然后在"执行策略"下拉框中选择"允许本地脚本和远程签名脚本"（对应RemoteSigned）或"允许所有脚本"（对应Unrestricted）。应用后，执行策略会被写入MachinePolicy作用域，优先级最高，低于组策略的用户本地设置都会被覆盖。

注册表方式比较底层，一般不需要用，但如果你在公司内网环境或者需要批量部署脚本，可以直接改注册表来实现。执行策略的注册表位置是：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell

在这个键下新建一个字符串值ExecutionPolicy，数值数据填RemoteSigned即可。CurrentUser范围的执行策略存放在：

HKEY_CURRENT_USER\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell

改注册表属于偏进阶的操作，日常开发用不上，了解即可。但如果你遇到Set-ExecutionPolicy命令都报"被组策略覆盖"的情况，说明机器已经由公司统一管理，这时候改本地注册表也大概率无效，得联系IT管理员处理。

4. 高频场景实战：npm、下载脚本、自启脚本

4.1 npm.ps1无法加载的解决实录

前端开发者遇到这个报错的比例最高。装完Node.js之后，在终端里执行npm install，PowerShell弹出：

npm : 无法加载文件 D:\nodejs\npm.ps1，因为在此系统上禁止运行脚本。

原因很简单：npm命令在Windows上是通过npm.ps1这个PowerShell脚本实现的。Node.js安装目录下的npm.ps1会作为npm命令的前置包装脚本被调用，当执行策略是Restricted时，PowerShell拒绝运行这个脚本，于是整个npm命令就挂了。

我实际的解决步骤是这样：

第一步，打开一个新的PowerShell窗口，先看一下当前策略：

Get-ExecutionPolicy

大概率返回Restricted。

第二步，执行修改命令：

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

第三步，输入Y确认。然后重新打开一个终端窗口，再执行npm install，一切正常。

注意，修改完策略之后，之前已经打开的那个终端窗口可能不会立即生效，尤其是VS Code自带的集成终端。这时候重启一下VS Code或者新建一个终端会话就好。这个问题我踩过，一直以为策略没改成功，其实是终端进程还保留了修改前的执行策略，重启解决一切。

如果你的npm还有其他问题，比如安装了Yarn、pnpm、Corepack等包管理器，它们的.ps1脚本同样会被默认策略拦截，处理方法完全一样。所以，其实你只要把执行策略改到RemoteSigned，所有包管理器命令都能一并解决，不用逐个去处理。

4.2 用PowerShell下载并运行脚本

另一种常见场景是下载脚本然后执行。比如，有些工具安装脚本需要先下载再运行：

Invoke-WebRequest -Uri "https://example.com/install.ps1" -OutFile "install.ps1" .\install.ps1

这种情况下，即使你把执行策略改成了RemoteSigned，依然可能被拦截。因为从互联网下载的文件会被Windows标记为"来自网络"，而这个标记（Zone.Identifier交替数据流）会成为脚本执行的额外检查因素。RemoteSigned策略要求这类脚本必须有受信任的发布者签名，没有签名就禁止运行。

此时有几个办法。最直接的，下载后右键点击文件 -> 属性 -> 在"常规"选项卡底部，把"安全"旁边的"解除锁定"复选框勾选上。解除锁定之后，这个文件就相当于"本地文件"了，RemoteSigned策略就会放行。

如果不想手动操作，也可以在PowerShell里用Unblock-File命令：

Unblock-File .\install.ps1

这个命令会自动去除文件上的"来自网络"标记，效果和右键勾选"解除锁定"一样，但更省事。

如果是临时测试，不想解除锁定也不想管签名，最简单的还是用Bypass方式运行：

powershell -ExecutionPolicy Bypass -File .\install.ps1

4.3 开机自启脚本的设置

有些朋友为了让工作更自动化，会把一些PowerShell脚本设置为开机自动运行。这时候执行策略同样是个拦路虎。我见过不少人兴冲冲地设置了任务计划程序，结果开机后脚本因为被禁止运行而在后台报错。

设置开机自启脚本，推荐两种方式。第一种是使用任务计划程序。打开任务计划程序，创建基本任务，触发器选"当计算机启动时"，操作选"启动程序"，程序填powershell.exe，参数填：

-ExecutionPolicy Bypass -File "D:\scripts\startup.ps1"

注意，我用的是-ExecutionPolicy Bypass，而不是依赖全局执行策略。原因是任务计划程序在系统启动阶段运行，所在的进程环境可能跟普通用户会话不同，直接依赖全局策略容易出意外。加上Bypass参数，保证脚本无论如何都能跑起来，而且只影响这个后台进程，不会影响别的程序。

第二种方式是使用启动文件夹。把脚本的快捷方式放到shell:startup目录中，但快捷方式的目标要设置成：

powershell.exe -NoProfile -ExecutionPolicy Bypass -File "D:\scripts\startup.ps1"

同样是为了绕过策略限制。这个方法适合简单的自启脚本，不需要管理员权限就能设置。

我给这两个方案插一句话：自启脚本因为涉及系统启动流程，运行出错时很难第一时间发现，建议在脚本里做好日志记录。我习惯在ps1脚本开头加上：

$logFile = "D:\logs\startup_$(Get-Date -Format 'yyyyMMdd').log" Start-Transcript -Path $logFile

这样脚本每次运行都会留一个日志文件，出问题也好追踪。

5. 常见问题与排查技巧实录

5.1 修改策略时报错怎么办

很多人执行Set-ExecutionPolicy时，会遇到几个典型的错误。

第一个是"拒绝访问"。这个通常发生在没有以管理员身份运行的PowerShell窗口里，试图修改LocalMachine作用域。解决方式是换到管理员窗口，或者改用CurrentUser作用域。

第二个是"找不到注册表项"或"路径不存在"。这个一般是你指定了不存在的Scope参数。检查一下命令拼写是不是准确，比如CurrentUser是连在一起的，不是Current_User。

第三个是"策略被组策略覆盖"。如果你执行命令后看到类似"已设置该策略，但由组策略覆盖"的提示，说明当前机器处于域环境或者被配置了组策略。这种时候不要跟系统硬杠，去问IT管理员要权限，或者请他们调整组策略。

还有一个很容易被忽视的问题：不同PowerShell版本，Set-ExecutionPolicy的行为有细微差异。比如Windows PowerShell 5.1和PowerShell 7，在某些系统上策略存储位置不一样。如果你同时装了多个PowerShell版本，最好在每个版本里分别执行Get-ExecutionPolicy确认一下。巧的是，我遇到过在Windows PowerShell 5.1里设置了RemoteSigned，但PowerShell 7里仍然是Restricted的情况，因为两者的配置路径不共用。

5.2 为什么改完还是不行

这个问题我见过太多次了，包括我自己早期也犯过。明明执行了Set-ExecutionPolicy RemoteSigned，返回成功，但再运行脚本还是报"禁止运行脚本"。排查思路按顺序走：

第一，确认你是在当前那个报错的终端里检查的。如果你改完策略后，实际运行的脚本是在另一个终端窗口里执行的，而这个窗口是在策略修改之前打开的，它可能还持有旧的策略状态。关掉所有PowerShell窗口，重新打开一个再试。

第二，确认Get-ExecutionPolicy的输出。如果你用Get-ExecutionPolicy看到的结果还是Restricted，说明修改的作用域没对上。用Get-ExecutionPolicy -List看看所有作用域的情况，重点检查是否有更高优先级的作用域覆盖了你的设置。

第三，确认脚本本身有没有其他问题。有些时候，你以为错误是执行策略的，但脚本实际上是编码格式不对、路径不存在、或者其他语法错误，只是报错信息恰好跟执行策略相关。仔细看报错的具体内容，是"禁止运行脚本"还是"文件不存在"或者"不是有效的PowerShell脚本"。

第四，检查PowerShell版本。如果你的系统是Windows 7或者老版本Windows Server，环境里可能只有PowerShell 2.0或3.0，这些版本的执行策略行为跟5.1/7有一定差异。我建议把PowerShell升到5.1以上，不仅功能更完善，执行策略管理也更好用。

5.3 安全建议与反悔指南

执行策略改完之后，有些人图省事直接用Unrestricted，还有人建议直接关掉UAC。我的态度很明确：不要用Unrestricted，更不要关UAC。执行策略是Windows安全体系的一部分，保留一个合理的策略等级，能在很大概率上阻止恶意脚本自动运行。

如果只是自己写脚本、跑包管理器命令，RemoteSigned绝对够了。偶尔运行不信任的脚本，用Bypass临时跑一次就好。我自己在用了四年RemoteSigned之后，从来没有遇到过正常开发流程被误拦截的情况，也从来没有因为策略太宽松中过脚本病毒。

最后讲讲如何回滚。如果你改了策略之后想恢复默认，比较简单。在管理员PowerShell里执行：

Set-ExecutionPolicy Restricted

或者，如果你只想删掉当前用户的设置，恢复为继承本地默认策略：

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Undefined

执行完再运行Get-ExecutionPolicy -List，确认状态符合预期。需要说明的是，把策略改回Restricted之后，你的npm、yarn、pnpm等命令又会回到"禁止运行脚本"的状态，所以这个操作适合你确定不再需要运行脚本的时候再做。

最后一个实用小技巧，如果你经常需要在多个机器或多个环境中切换执行策略，可以写一个简短的PowerShell函数放到profile里：

function Set-DevPolicy { Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned -Force Write-Host "Development execution policy is set to RemoteSigned." }

写入profile文件后，新开一个PowerShell窗口，手动执行Set-DevPolicy就能一键把策略调整到开发模式。用起来非常顺手，推荐给频繁重装环境或者经常使用多台机器的朋友。