1. 问题定位与背景解析如果你在 Windows 上搞前端开发特别是用上了 pnpm 这类现代包管理器那大概率在某个时刻打开 PowerShell 或终端时会迎面撞上这个令人头疼的红色错误pnpm : 无法加载文件 C:\Users\你的用户名\AppData\Roaming\npm\pnpm.ps1因为在此系统上禁止运行脚本。有关详细信息请参阅 https:/go.microsoft.com/fwlink/?LinkID135170 中的 about_Execution_Policies。 所在位置 行:1 字符: 1 pnpm install ~~~~ CategoryInfo : SecurityError: (:) [] PSSecurityException FullyQualifiedErrorId : UnauthorizedAccess这个报错的核心根本不是 pnpm 本身坏了或者没装对。它本质上是 Windows PowerShell 这个“门卫”在严格执行它的安全规则把你当成一个潜在的“危险分子”给拦在了门外。这个“门卫”的名字就叫执行策略。很多新手甚至一些有经验的开发者一看到这个错误就慌了开始重装 Node.js、重装 pnpm、甚至怀疑系统有问题。其实大可不必我们得先理解这个“门卫”的职责和规矩。Windows 系统默认的 PowerShell 执行策略是Restricted这是最严格的一档。你可以把它想象成你家小区的保安他的职责是“禁止任何外部脚本进入”。在这种策略下PowerShell 只能运行交互式命令任何.ps1脚本文件比如 pnpm 安装后生成的pnpm.ps1都会被无情地拒之门外。pnpm 为了提供更快的命令响应和更好的用户体验在通过 npm 全局安装时npm install -g pnpm会在C:\Users\用户名\AppData\Roaming\npm目录下创建一个 PowerShell 脚本文件pnpm.ps1并设置一个名为pnpm的命令别名指向它。当你输入pnpm命令时PowerShell 实际尝试执行的就是这个脚本。于是严格的“门卫”和想进门的“脚本”就发生了冲突。所以解决这个问题的思路非常清晰不是拆掉门卫那不安全而是告诉门卫我们这位叫pnpm.ps1的访客是可信的可以放行。具体方法就是调整 PowerShell 的“放行规则”也就是修改它的执行策略。1.1 理解 PowerShell 执行策略的几种模式在动手修改之前我们有必要了解一下 PowerShell 为我们提供的几种“安全等级”这能帮助我们做出最合适的选择而不是盲目地选择最宽松的那个。你可以通过命令Get-ExecutionPolicy来查看当前用户在当前作用域下的策略。Restricted默认这是最严格的模式。系统就像一座堡垒禁止运行任何脚本文件.ps1,.psm1,.psd1等只允许执行交互式命令。这是 Windows 客户端系统的出厂设置旨在最大程度防止恶意脚本自动执行。AllSigned这个模式相对宽松但依然严格。它允许运行脚本但有一个硬性前提脚本必须由受信任的发布者进行数字签名。如果脚本没有签名或者签名来自不受信任的发布者则会被阻止。这适合对安全要求极高的企业环境但对于我们日常开发来说过于繁琐因为你自己写的脚本或者很多开源工具如 pnpm的脚本都不会去搞数字签名。RemoteSigned这是推荐给大多数开发者的平衡选项。它对从互联网下载的脚本如邮件附件、网页下载要求必须有受信任的签名才能运行但对于在本地计算机上创建的脚本比如你通过 npm 安装在本地磁盘上的pnpm.ps1则可以直接运行。这就在安全性和便利性之间取得了很好的平衡。Unrestricted这个模式就非常开放了。它会运行所有脚本但在运行从网上下载的、未签名的脚本前会弹出一个确认提示。虽然给了你选择权但频繁的提示也很烦人并且存在因误操作而运行恶意脚本的风险。Bypass这个模式完全绕过了所有安全限制和提示来者不拒。强烈不建议在日常使用中设置此策略它会让你的系统门户大开极其危险。Undefined表示在当前作用域没有设置策略最终会继承更高层级作用域如LocalMachine的策略。对于我们解决 pnpm 报错这个具体场景目标就是将策略从默认的Restricted改为RemoteSigned。这样本地安装的pnpm.ps1就能顺利运行同时系统对来自外部的脚本仍保持一定的警惕性。注意修改执行策略只会影响 PowerShell 脚本.ps1等的运行不会影响普通的可执行文件.exe,.bat,.cmd。所以即使你修改了策略系统整体的安全性依然有保障不必过分担心。2. 解决方案实操四种修改执行策略的方法理解了问题的根源和可选策略后我们就可以动手解决了。这里有四种主流方法从最推荐到备选方案你可以根据你的使用习惯和系统权限来选择。2.1 方法一以管理员身份运行 PowerShell 并修改策略最通用这是最经典、最可靠的方法适用于所有版本的 WindowsWin7, Win10, Win11。操作步骤以管理员身份启动 PowerShell在 Windows 搜索框输入PowerShell。在搜索结果中的“Windows PowerShell”上右键单击选择“以管理员身份运行”。这是关键一步因为修改机器级别的执行策略需要管理员权限。你会看到一个带有“管理员”前缀的蓝色窗口。查看当前执行策略可选用于确认Get-ExecutionPolicy通常它会返回Restricted。将执行策略设置为 RemoteSignedSet-ExecutionPolicy RemoteSigned执行这条命令后PowerShell 会给出一个安全警告询问你是否要更改执行策略。它可能会显示类似这样的文字执行策略更改 执行策略可帮助你防止执行不信任的脚本。更改执行策略可能会产生安全风险如 https:/go.microsoft.com/fwlink/?LinkID135170 中的 about_Execution_Policies 帮助主题所述。是否要更改执行策略 [Y] 是(Y) [A] 全是(A) [N] 否(N) [L] 全否(L) [S] 暂停(S) [?] 帮助 (默认值为“N”):这里你需要输入Y然后按回车表示确认更改。验证更改Get-ExecutionPolicy现在它应该返回RemoteSigned。关闭管理员 PowerShell重新打开你平常使用的终端可以是 PowerShell也可以是 VS Code 的终端、Windows Terminal 等再次尝试运行pnpm --version或pnpm install错误应该已经消失了。为什么这个方法最通用因为它修改的是LocalMachine本地计算机作用域的策略这是影响范围最广的层级。一旦设置成功所有用户在该计算机上的所有 PowerShell 会话包括非管理员会话都会继承这个策略。一劳永逸。实操心得务必确保你是在“以管理员身份运行”的 PowerShell 中执行Set-ExecutionPolicy命令否则会收到“拒绝访问”的错误。输入Y确认时看清楚提示别输错了。有些系统可能默认选项是N否你需要手动输入Y。2.2 方法二为当前用户单独设置策略无需管理员权限如果你没有管理员权限或者你只想为当前登录的账户修改策略不影响其他用户可以使用这个方法。它通过-Scope参数指定作用域。操作步骤打开 PowerShell普通用户身份即可无需管理员。执行以下命令Set-ExecutionPolicy RemoteSigned -Scope CurrentUser同样会弹出确认提示输入Y并回车。验证当前用户作用域的策略Get-ExecutionPolicy -Scope CurrentUser应返回RemoteSigned。同时你可以检查机器级策略是否还是原来的Get-ExecutionPolicy -Scope LocalMachine可能仍是Restricted。这个方法的优缺点优点不需要管理员权限操作更灵活只影响你自己的账户。缺点如果你切换了用户账户或者在某些集成开发环境IDE中终端可能以其他用户或系统身份运行这个设置可能不生效。它的优先级低于LocalMachine作用域。什么时候用这个方法当你是在公司电脑、学校机房等没有管理员权限的受控环境中遇到此问题时这是你的首选方案。2.3 方法三在命令中临时绕过策略单次生效如果你只是临时需要运行一次 pnpm 命令或者你完全不想修改系统设置可以采用这种“一次性”的方案。它通过在运行命令时附加参数临时改变本次 PowerShell 会话的执行策略。操作步骤打开 PowerShell。使用以下格式运行你的 pnpm 命令powershell -ExecutionPolicy Bypass -Command pnpm install或者如果你已经在 PowerShell 环境中可以这样Set-ExecutionPolicy Bypass -Scope Process -Force pnpm install命令解析-ExecutionPolicy Bypass为本次启动的 PowerShell 进程设置执行策略为Bypass完全绕过。-Command pnpm install指定要执行的命令。Set-ExecutionPolicy Bypass -Scope Process -Force-Scope Process表示只对当前 PowerShell 进程生效-Force参数强制设置不显示确认提示。这个方法的优缺点优点完全不影响系统全局或用户级别的设置最安全、最干净。适合在自动化脚本、Docker 容器初始化等场景中使用。缺点每次运行 pnpm 命令都需要加上前缀非常麻烦不适合日常开发。实操心得我通常只在写一些自动化部署脚本或者在不属于自己的机器上快速测试时使用这种方法。对于自己的主力开发机还是用方法一或方法二一劳永逸地解决掉更省心。2.4 方法四使用 Windows Terminal 或 VS Code 集成终端如果你日常使用的是 Windows Terminal 或 VS Code 内置的终端并且它们默认的 Shell 配置文件是 PowerShell那么上述方法同样适用。你只需要在对应的终端窗口里以管理员身份运行 PowerShell 标签页在 Windows Terminal 中可以点击下拉箭头选择“以管理员身份运行”然后执行Set-ExecutionPolicy RemoteSigned即可。一个小技巧在 VS Code 中如果你不想每次都开管理员终端可以修改终端默认的启动 Shell。但更简单的做法是确保你的用户级执行策略方法二已经设置正确因为 VS Code 的终端通常以当前用户身份运行。3. 深入排查与进阶问题解决按照上述方法操作后99% 的情况下问题就解决了。但开发环境千奇百怪如果你发现改了策略还是报错或者遇到了其他相关的问题别急我们可以按照以下步骤进行深度排查。3.1 检查策略生效范围与优先级执行策略是有作用域和优先级的。优先级从高到低是ProcessCurrentUserLocalMachine。你可以用以下命令查看所有作用域的策略Get-ExecutionPolicy -List输出类似Scope ExecutionPolicy ----- --------------- MachinePolicy Undefined UserPolicy Undefined Process Undefined CurrentUser RemoteSigned LocalMachine Restricted在这个例子中CurrentUser是RemoteSigned而LocalMachine是Restricted。根据优先级当前进程会采用CurrentUser的策略 (RemoteSigned)所以 pnpm 应该能运行。如果CurrentUser是Undefined或Restricted而LocalMachine是Restricted那么最终生效的策略就是Restricted。如果策略设置后不生效检查以下几点你是否在正确的 PowerShell 会话中验证关闭所有终端窗口重新打开一个再试。你是否使用了-Scope参数如果你用Set-ExecutionPolicy RemoteSigned -Scope CurrentUser设置那么用Get-ExecutionPolicy不带参数查看的是默认作用域通常是LocalMachine的策略。应该用Get-ExecutionPolicy -Scope CurrentUser来验证。是否有组策略覆盖在域管理的企业环境中组策略 (MachinePolicy或UserPolicy) 可能会强制锁定执行策略使你无法更改。如果Get-ExecutionPolicy -List显示MachinePolicy或UserPolicy被设置为某个值那么你需要联系系统管理员。3.2 路径与命令别名问题有时候报错信息可能略有不同或者改了策略后依然找不到命令。这时需要检查 pnpm 的安装路径和 PowerShell 的配置文件。检查 pnpm 是否真的已全局安装npm list -g pnpm或者直接去C:\Users\你的用户名\AppData\Roaming\npm\node_modules目录下看看有没有pnpm文件夹。检查 npm 全局路径是否在系统 PATH 中pnpm.ps1所在的目录C:\Users\你的用户名\AppData\Roaming\npm必须位于系统的 PATH 环境变量中PowerShell 才能找到它。在 PowerShell 中输入$env:Path查看当前 PATH。检查输出中是否包含上述 npm 路径。如果没有你需要手动添加。添加 PATH 方法以 Win11 为例系统设置 - 系统 - 关于 - 高级系统设置 - 环境变量。在“用户变量”或“系统变量”中找到Path点击编辑。新建一条填入C:\Users\你的用户名\AppData\Roaming\npm请将“你的用户名”替换为实际用户名。确定保存后重启所有终端窗口使其生效。检查 PowerShell 配置文件 pnpm 通过 npm 安装时可能会尝试修改 PowerShell 的配置文件如$PROFILE来创建命令别名。有时配置文件损坏或加载异常会导致问题。你可以尝试在 PowerShell 中执行Test-Path $PROFILE如果返回False说明配置文件不存在可以运行pnpm setup命令来让 pnpm 尝试重新配置。如果返回True可以运行notepad $PROFILE打开配置文件检查其中是否有关于 pnpm 的错误或重复配置。3.3 与杀毒软件或安全软件的冲突少数情况下过于激进的安全软件或 Windows Defender 的某些设置可能会拦截 PowerShell 脚本的执行即使执行策略已经放宽。如果你确认执行策略设置正确但问题依旧可以尝试暂时禁用实时病毒防护操作前请确保你信任当前操作环境然后测试 pnpm 命令。将C:\Users\你的用户名\AppData\Roaming\npm目录添加到安全软件的信任区或排除列表。3.4 使用 PowerShell Core (v7) 或 Windows Terminal如果你追求更现代化的终端体验可以考虑升级到PowerShell Core (v7)它是 PowerShell 的开源跨平台版本。其默认执行策略在 Windows 上可能有所不同且性能和新特性都更好。你可以通过 Microsoft Store 或 GitHub 发布页安装。Windows Terminal是一个强大的终端应用程序可以同时管理 PowerShell、CMD、WSL、Azure Cloud Shell 等多种 Shell。它本身不改变执行策略但提供了更便捷的方式来以管理员身份启动各种 Shell并拥有丰富的自定义功能如多标签、分屏、主题等。对于开发者来说使用 Windows Terminal PowerShell 7 是一个非常好的组合。4. 常见问题与排查技巧实录在实际操作中除了核心的“禁止运行脚本”错误大家可能还会遇到一些衍生问题或迷惑点。这里我整理了一个速查表并附上我的排查思路。问题现象可能原因排查步骤与解决方案运行pnpm命令后报错信息中路径是C:\Program Files\nodejs\pnpm.ps1或其他路径。pnpm 可能通过其他方式安装如独立安装脚本或者存在多个安装版本冲突。1. 运行where pnpm(CMD) 或Get-Command pnpm(PowerShell) 查看系统找到的 pnpm 命令位置。2. 运行npm list -g pnpm查看 npm 全局安装的版本。3. 如果存在多个建议卸载冲突版本npm uninstall -g pnpm然后重新通过npm install -g pnpm安装。修改执行策略时提示“Set-ExecutionPolicy对注册表项‘HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell’的访问被拒绝。”没有使用管理员身份运行 PowerShell。关闭当前 PowerShell 窗口重新右键点击“Windows PowerShell”选择“以管理员身份运行”再执行设置命令。执行策略已改为RemoteSigned但运行pnpm仍报同样的安全错误。1. 策略未正确应用到当前会话。2. 脚本文件签名问题极少见。3. 路径或别名问题。1.重启终端或新开一个 PowerShell 窗口再试。2. 运行Get-ExecutionPolicy -List确认CurrentUser或LocalMachine作用域的策略已生效。3. 尝试运行powershell -ExecutionPolicy RemoteSigned -Command pnpm --version测试临时策略是否有效。错误信息变成“pnpm.ps1 无法被加载因为文件...未经过数字签名。”执行策略可能被意外设为AllSigned或者脚本被修改导致签名无效。1. 检查执行策略Get-ExecutionPolicy。2. 如果是AllSigned改为RemoteSignedSet-ExecutionPolicy RemoteSigned。3. 极端情况下可以删除pnpm.ps1文件然后运行pnpm setup或重装 pnpm 让其重新生成。在 VS Code 终端里报错但在独立的 PowerShell 里正常。VS Code 的终端可能以不同的用户身份或不同的 Shell 启动或者其集成控制台有特殊的执行策略设置。1. 检查 VS Code 终端右下角显示的 Shell 类型如 PowerShell, bash, cmd。2. 在 VS Code 终端里运行$PSVersionTable和Get-ExecutionPolicy确认其 PowerShell 版本和执行策略。3. 确保在 VS Code 使用的 Shell 类型如 PowerShell中也正确设置了执行策略。运行任何npm或npx命令也出现类似的“.ps1 禁止运行”错误。与 pnpm 同理npm 在安装某些全局包如create-react-app,vue-cli等时也会创建.ps1脚本。解决方案完全一样将 PowerShell 执行策略修改为RemoteSigned或Unrestricted推荐RemoteSigned。独家避坑技巧“一劳永逸”的配置脚本如果你经常需要配置新电脑或重装系统可以创建一个 PowerShell 脚本来自动化这个过程。新建一个setup-dev.ps1文件内容如下# 以管理员身份运行此脚本 Set-ExecutionPolicy RemoteSigned -Force # 安装 Node.js (如果使用 winget) winget install -e --id OpenJS.NodeJS.LTS # 安装 pnpm npm install -g pnpm # 设置 pnpm 镜像可选 pnpm config set registry https://registry.npmmirror.com/以后在新环境只需右键“以管理员身份运行”这个脚本即可。注意首次运行自己写的.ps1脚本可能也会被阻止你需要先对脚本文件右键 - 属性 - 勾选“解除锁定”或者先用方法三的临时策略运行一次这个配置脚本。区分 PowerShell 与 CMD这个问题只发生在 PowerShell 或兼容 PowerShell 的终端如 Windows Terminal 的 PowerShell 标签中。如果你在传统的命令提示符 (CMD)中运行pnpm它是通过.cmd文件调用的完全不受 PowerShell 执行策略的影响。所以一个临时的解决办法就是用 CMD 终端。但这只是权宜之计因为很多现代前端工具链和教程都默认使用 PowerShell 环境。使用pnpm setup命令pnpm 提供了一个官方的配置命令pnpm setup。这个命令会尝试自动完成几件事将 pnpm 的全局 bin 目录添加到系统 PATH并可能尝试修复 PowerShell 的配置文件。在解决路径问题和配置文件问题时运行一下这个命令可能会有意外收获。