1. 这个报错到底卡在哪一步如果你在 Windows 上敲下npx create-react-app my-app或者只是想跑一下npm -v验证 Node.js 装好没有结果终端甩回来一句npx : 无法加载文件 C:\Program Files\nodejs\npx.ps1因为在此系统上禁止运行脚本。第一反应通常是我 Node.js 是不是装坏了是不是环境变量没配然后开始重装 Node、重启电脑、换版本折腾一圈发现报错纹丝不动。问题根本不在 Node.js而在你敲命令的那个壳——PowerShell 的执行策略Execution Policy。这个报错的完整含义是PowerShell 在尝试加载npx.ps1这个脚本文件时被系统层面的策略拦住了。注意关键词是.ps1不是.exe。Node.js 安装包在 Windows 上会同时放两套入口一套是给 CMD 用的.cmd批处理一套是给 PowerShell 用的.ps1脚本。你在 PowerShell 里执行npx它优先找的是npx.ps1而 PowerShell 默认策略是Restricted——禁止运行任何脚本文件。所以这件事的本质是Node.js 没问题npm 没问题npx 也没问题是 PowerShell 不让你跑脚本。适合读这篇的人有三类刚装完 Node.js 准备跑第一个项目的新手在 Windows 上做前端或 Node 后端开发、经常和终端打交道的工程师以及那些被公司电脑组策略锁死、改不动执行策略的倒霉蛋。下面我把这个坑从原理到解法到避坑完整拆一遍。2. PowerShell 执行策略的设计逻辑与四种模式2.1 为什么 PowerShell 默认要禁止脚本很多人觉得这个默认设置很反人类但它有明确的历史原因。PowerShell 的脚本能力极强一个.ps1文件可以调用系统 API、修改注册表、下载并执行远程内容。如果默认放开用户双击一个来源不明的脚本就可能中招。所以微软把默认策略设成Restricted意思是交互式命令可以敲脚本文件一律不许跑。这跟 CMD 的.bat不一样。CMD 从来没有类似的脚本拦截机制所以你在 CMD 里跑npx从来不会遇到这个问题。PowerShell 因为设计上更重安全默认值就更保守。理解这一点很关键这不是 bug是 feature只是它和 Node.js 生态的默认工作方式撞车了。2.2 四种执行策略的实际区别PowerShell 的执行策略不是简单的开/关而是分了好几档。搞清它们的区别你才知道自己该选哪个。策略名称能否跑本地脚本能否跑远程签名脚本能否跑远程未签名脚本适用场景Restricted否否否系统默认最严格RemoteSigned是是否开发机推荐AllSigned是需签名是需签名否企业受控环境Unrestricted是是是会提示临时排错不推荐长期这里有个特别容易踩的坑RemoteSigned对本地脚本是完全放行的。也就是说你本机安装 Node.js 时生成的npx.ps1、npm.ps1属于本地文件RemoteSigned下可以直接跑。只有从网络下载的、没有数字签名的脚本才会被拦。这就是为什么开发机普遍推荐RemoteSigned——既解决了 npx 的问题又保留了对远程恶意脚本的防线。而Unrestricted虽然什么都能跑但它对远程未签名脚本只是提示后放行并不是真正安全而且很多企业环境会通过组策略强制覆盖你改了也白改。2.3 执行策略的作用范围层级执行策略可以设在五个不同的作用域上优先级从高到低是MachinePolicyUserPolicyProcessCurrentUserLocalMachine。这个层级关系是排查问题的关键。如果你用Set-ExecutionPolicy改了LocalMachine但公司 IT 通过组策略下发了MachinePolicy那你的修改会被静默覆盖Get-ExecutionPolicy显示的还是被锁死的值。这就是为什么有些人改了策略、重启后又失效——不是没生效是被更高优先级的作用域压住了。查看当前所有作用域的实际值用这条命令Get-ExecutionPolicy -List输出会列出每个作用域各自的策略。如果MachinePolicy或UserPolicy显示为Restricted或AllSigned那基本可以确定是域控或本地安全策略在管普通用户改不动。3. 三种解法从临时绕过到永久修复3.1 只影响当前窗口的 Process 级修改如果你只是想赶紧把项目跑起来不想动系统设置最轻量的做法是在当前 PowerShell 窗口里临时改Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process这条命令只对当前这个 PowerShell 会话生效关掉窗口就恢复原样。好处是零副作用、不需要管理员权限、不会影响系统其他部分。坏处是每开一个新窗口都得重新敲一遍。我个人的习惯是在写一次性脚本、跑临时任务时用Process级在配置一台长期开发机时用CurrentUser级。这样既不会污染系统全局又能保证日常使用不被打断。3.2 对当前用户永久生效的 CurrentUser 级修改这是绝大多数个人开发机最推荐的方案Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUserCurrentUser作用域只影响你当前登录的这个账户不需要管理员权限也不会影响同一台机器上的其他用户。执行完可以用Get-ExecutionPolicy -List确认CurrentUser那一行变成了RemoteSigned。这里有个细节要注意如果你之前从没设置过CurrentUser作用域它的默认值可能是Undefined。Undefined的意思是跟随更高优先级的作用域不是禁止。所以当你把它显式设成RemoteSigned后它就固定下来了不会再被LocalMachine的默认值影响。3.3 需要管理员权限的 LocalMachine 级修改如果你想让整台机器所有用户都生效或者你就是这台机器的管理员可以用Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine这条命令需要以管理员身份运行 PowerShell。执行后所有用户都会继承这个策略除非被CurrentUser或组策略覆盖。但我要提醒一句在多人共用的机器上改LocalMachine要谨慎。它会影响其他用户的脚本运行行为如果这台机器还跑着某些依赖严格策略的自动化任务可能会出问题。个人电脑随便改公司资产最好先问清楚。3.4 三种方案的对比与选择建议方案作用范围需要管理员持久性推荐场景Process当前窗口否关窗即失效临时跑一次CurrentUser当前用户否永久个人开发机首选LocalMachine全机器是永久单人多机或管理员选择逻辑很简单能不动系统就不动系统能只影响自己就不影响别人。所以优先级是 Process CurrentUser LocalMachine。只有在CurrentUser被组策略锁死、改不动的时候才考虑往上找。4. 改完还是报错排查链路完整复盘4.1 第一步确认策略到底改没改成功很多人敲完Set-ExecutionPolicy看到没报错就以为成了其实可能被静默覆盖。正确的验证方式是Get-ExecutionPolicy -List看输出里CurrentUser那一行是不是你设的值。如果显示的还是Restricted说明有更高优先级的作用域在压制。这时候要看MachinePolicy和UserPolicy两行——只要它们不是Undefined你的修改就无效。4.2 第二步检查是不是组策略锁死如果MachinePolicy或UserPolicy显示为Restricted那就是域控或本地组策略在管。这种情况下Set-ExecutionPolicy会直接报错或者执行了也不生效。排查路径是打开gpedit.msc专业版/企业版才有找到计算机配置 管理模板 Windows 组件 Windows PowerShell看打开脚本执行这项是不是被设成了已禁用。家庭版 Windows 没有gpedit.msc但组策略依然可能通过注册表下发。对应的注册表位置是HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell如果这里存在ExecutionPolicy键值那就是被策略锁了。普通用户没有权限改这个键需要联系 IT 管理员。4.3 第三步绕过策略的临时手段在策略被锁死、又急需跑命令的情况下有一个不改策略的绕过方式直接用-ExecutionPolicy Bypass参数启动一个新的 PowerShell 进程。powershell -ExecutionPolicy Bypass -Command npx create-react-app my-appBypass的意思是本次进程内不应用任何执行策略它比Unrestricted更彻底连提示都没有。这个参数只对当前启动的这个进程有效不会改变系统设置。注意Bypass是排查和应急手段不要把它写进日常脚本或快捷方式里长期使用。它绕过了所有脚本防护等于把安全默认值完全关掉。4.4 第四步确认是不是 npm.ps1 本身的问题还有一种情况策略已经改成RemoteSigned了但报错依然存在只是报错内容变了。比如提示npm.ps1文件损坏或路径不对。这时候要检查 Node.js 安装目录下的.ps1文件是否完整。正常安装的 Node.js 会在安装目录下生成npm.ps1、npx.ps1、npm.cmd、npx.cmd这几个文件。如果.ps1缺失PowerShell 找不到就会报别的错。可以这样验证Get-ChildItem C:\Program Files\nodejs\ -Filter *.ps1如果列表是空的说明安装不完整重装 Node.js 即可。如果文件在但报错可能是文件被杀毒软件隔离或损坏同样重装解决。4.5 排查流程速查表现象可能原因验证命令解决方向报禁止运行脚本策略为 RestrictedGet-ExecutionPolicy -List改 CurrentUser 为 RemoteSigned改了策略仍报错被组策略覆盖看 MachinePolicy 行联系 IT 或临时 Bypass报文件不存在.ps1 缺失Get-ChildItem *.ps1重装 Node.js报文件损坏被杀软隔离检查杀软隔离区恢复或重装换 CMD 就好了只是 PowerShell 问题在 CMD 里跑 npx说明策略是唯一原因5. 比改策略更省心的替代路径5.1 直接用 CMD 或 Git Bash 绕开 PowerShell最省事的办法其实是不跟 PowerShell 较劲。CMD 没有执行策略这回事在 CMD 里跑npx直接就能用。Git Bash 同理它用的是类 Unix 的 shell也不受 PowerShell 策略影响。如果你只是偶尔跑一下 npm 命令完全可以把默认终端从 PowerShell 换成 CMD。在 Windows Terminal 里改默认配置文件就行设置 启动 默认终端应用程序选命令提示符。或者在 VS Code 里改terminal.integrated.defaultProfile.windows为Command Prompt。这个方案的好处是零配置、零风险、不碰系统设置。坏处是你失去了 PowerShell 的很多便利功能比如对象管道、更好的补全。所以它适合我只想跑命令不想折腾终端的人。5.2 用 npx.cmd 显式调用如果你坚持用 PowerShell又不想改策略可以在命令后面显式加.cmdnpx.cmd create-react-app my-app这样 PowerShell 会去找npx.cmd而不是npx.ps1绕过了脚本拦截。同理npm.cmd、yarn.cmd都可以这么用。这个技巧在写 CI 脚本或批处理时特别有用因为它不依赖任何策略设置在任何 Windows 环境下都能跑。缺点是每次都要多敲四个字符长期用有点烦。5.3 在 VS Code 里配置默认终端VS Code 的集成终端默认走 PowerShell所以新手在 VS Code 里跑 npm 命令最容易撞上这个报错。除了改默认终端类型还有一个办法是在 VS Code 的settings.json里给 PowerShell 配置启动参数{ terminal.integrated.profiles.windows: { PowerShell: { source: PowerShell, args: [-ExecutionPolicy, Bypass] } } }这样每次 VS Code 启动 PowerShell 终端时都会带上Bypass参数等于给集成终端单独开了绿灯不影响系统其他部分。这个配置我个人用了很久实测很稳推荐给不想动系统策略的人。5.4 各方案适用性对比方案改动范围持久性副作用推荐指数改 CurrentUser 策略当前用户永久无五星换 CMD 终端终端配置永久失去 PS 功能四星显式加 .cmd单条命令无多敲字符三星VS Code Bypass编辑器内永久仅限 VS Code四星临时 Bypass 进程单次进程无无防护二星6. 几个容易忽略的连带问题6.1 执行策略和脚本签名是两回事有些人把执行策略改成AllSigned后发现连自己写的本地脚本都跑不了因为AllSigned要求所有脚本包括本地的都必须有数字签名。这时候要么改回RemoteSigned要么给自己的脚本签名。个人开发机没必要用AllSigned那是给企业受控环境准备的。6.2 中文路径和空格路径的坑Node.js 默认装在C:\Program Files\nodejs\这个路径里有空格。PowerShell 在处理带空格的路径时如果脚本内部没有正确加引号可能会解析出错。虽然执行策略问题跟路径空格没直接关系但如果你把 Node 装到了带中文或空格的目录后续可能遇到其他奇怪报错。建议 Node.js 装在纯英文无空格路径下比如C:\nodejs\。6.3 多版本 Node 管理器的策略冲突用 nvm-windows 这类版本管理器切换 Node 版本时每次切换都会重新生成 shim 文件。如果这些 shim 是.ps1格式同样会受执行策略影响。所以用了版本管理器的人更要把CurrentUser策略设成RemoteSigned否则每次切版本都可能触发报错。6.4 系统更新后策略被重置Windows 大版本更新有时会重置部分系统设置包括执行策略。如果你某天突然又看到这个报错先别怀疑 Node直接Get-ExecutionPolicy -List看一眼大概率是策略被改回去了。重新设一遍CurrentUser即可。6.5 远程桌面和虚拟机环境的特殊性在远程桌面或虚拟机里操作时执行策略可能继承宿主机的组策略设置。有些虚拟机模板默认就是Restricted而且CurrentUser作用域被锁。这种情况下优先用Process级临时修改或者直接用 CMD别在策略上死磕。7. 我踩过的几个真实坑第一次遇到这个报错时我的反应是重装 Node.js装了三遍报错一模一样。后来才意识到问题在 PowerShell 不在 Node。这个教训让我养成了一个习惯看到.ps1相关的报错先查执行策略别动 Node。第二个坑是改了LocalMachine却没生效。当时在一台公司电脑上用管理员权限改了LocalMachine为RemoteSignedGet-ExecutionPolicy显示也是RemoteSigned但跑 npx 还是报错。后来用-List一看MachinePolicy是Restricted组策略压着我改的LocalMachine根本不起作用。这个坑让我明白单看Get-ExecutionPolicy不够必须看-List的完整层级。第三个坑是Bypass用顺手了。有段时间我把所有 PowerShell 快捷方式都加上了-ExecutionPolicy Bypass图省事。后来意识到这等于把整台机器的脚本防护全关了任何下载来的脚本都能静默执行。赶紧改回RemoteSigned。Bypass 是应急工具不是日常配置。最后一个经验如果你经常在不同机器之间切换把设置策略的命令写成一个初始化脚本新机器上跑一次就行。我自己的初始化脚本里就有这么一行Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force-Force参数的作用是跳过确认提示适合写在自动化脚本里。这样每台新机器配置环境时这一步永远不会漏。 Windows 上 npx 报错禁止运行脚本？PowerShell 执行策略原理与修复指南
1. 这个报错到底卡在哪一步如果你在 Windows 上敲下npx create-react-app my-app或者只是想跑一下npm -v验证 Node.js 装好没有结果终端甩回来一句npx : 无法加载文件 C:\Program Files\nodejs\npx.ps1因为在此系统上禁止运行脚本。第一反应通常是我 Node.js 是不是装坏了是不是环境变量没配然后开始重装 Node、重启电脑、换版本折腾一圈发现报错纹丝不动。问题根本不在 Node.js而在你敲命令的那个壳——PowerShell 的执行策略Execution Policy。这个报错的完整含义是PowerShell 在尝试加载npx.ps1这个脚本文件时被系统层面的策略拦住了。注意关键词是.ps1不是.exe。Node.js 安装包在 Windows 上会同时放两套入口一套是给 CMD 用的.cmd批处理一套是给 PowerShell 用的.ps1脚本。你在 PowerShell 里执行npx它优先找的是npx.ps1而 PowerShell 默认策略是Restricted——禁止运行任何脚本文件。所以这件事的本质是Node.js 没问题npm 没问题npx 也没问题是 PowerShell 不让你跑脚本。适合读这篇的人有三类刚装完 Node.js 准备跑第一个项目的新手在 Windows 上做前端或 Node 后端开发、经常和终端打交道的工程师以及那些被公司电脑组策略锁死、改不动执行策略的倒霉蛋。下面我把这个坑从原理到解法到避坑完整拆一遍。2. PowerShell 执行策略的设计逻辑与四种模式2.1 为什么 PowerShell 默认要禁止脚本很多人觉得这个默认设置很反人类但它有明确的历史原因。PowerShell 的脚本能力极强一个.ps1文件可以调用系统 API、修改注册表、下载并执行远程内容。如果默认放开用户双击一个来源不明的脚本就可能中招。所以微软把默认策略设成Restricted意思是交互式命令可以敲脚本文件一律不许跑。这跟 CMD 的.bat不一样。CMD 从来没有类似的脚本拦截机制所以你在 CMD 里跑npx从来不会遇到这个问题。PowerShell 因为设计上更重安全默认值就更保守。理解这一点很关键这不是 bug是 feature只是它和 Node.js 生态的默认工作方式撞车了。2.2 四种执行策略的实际区别PowerShell 的执行策略不是简单的开/关而是分了好几档。搞清它们的区别你才知道自己该选哪个。策略名称能否跑本地脚本能否跑远程签名脚本能否跑远程未签名脚本适用场景Restricted否否否系统默认最严格RemoteSigned是是否开发机推荐AllSigned是需签名是需签名否企业受控环境Unrestricted是是是会提示临时排错不推荐长期这里有个特别容易踩的坑RemoteSigned对本地脚本是完全放行的。也就是说你本机安装 Node.js 时生成的npx.ps1、npm.ps1属于本地文件RemoteSigned下可以直接跑。只有从网络下载的、没有数字签名的脚本才会被拦。这就是为什么开发机普遍推荐RemoteSigned——既解决了 npx 的问题又保留了对远程恶意脚本的防线。而Unrestricted虽然什么都能跑但它对远程未签名脚本只是提示后放行并不是真正安全而且很多企业环境会通过组策略强制覆盖你改了也白改。2.3 执行策略的作用范围层级执行策略可以设在五个不同的作用域上优先级从高到低是MachinePolicyUserPolicyProcessCurrentUserLocalMachine。这个层级关系是排查问题的关键。如果你用Set-ExecutionPolicy改了LocalMachine但公司 IT 通过组策略下发了MachinePolicy那你的修改会被静默覆盖Get-ExecutionPolicy显示的还是被锁死的值。这就是为什么有些人改了策略、重启后又失效——不是没生效是被更高优先级的作用域压住了。查看当前所有作用域的实际值用这条命令Get-ExecutionPolicy -List输出会列出每个作用域各自的策略。如果MachinePolicy或UserPolicy显示为Restricted或AllSigned那基本可以确定是域控或本地安全策略在管普通用户改不动。3. 三种解法从临时绕过到永久修复3.1 只影响当前窗口的 Process 级修改如果你只是想赶紧把项目跑起来不想动系统设置最轻量的做法是在当前 PowerShell 窗口里临时改Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process这条命令只对当前这个 PowerShell 会话生效关掉窗口就恢复原样。好处是零副作用、不需要管理员权限、不会影响系统其他部分。坏处是每开一个新窗口都得重新敲一遍。我个人的习惯是在写一次性脚本、跑临时任务时用Process级在配置一台长期开发机时用CurrentUser级。这样既不会污染系统全局又能保证日常使用不被打断。3.2 对当前用户永久生效的 CurrentUser 级修改这是绝大多数个人开发机最推荐的方案Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUserCurrentUser作用域只影响你当前登录的这个账户不需要管理员权限也不会影响同一台机器上的其他用户。执行完可以用Get-ExecutionPolicy -List确认CurrentUser那一行变成了RemoteSigned。这里有个细节要注意如果你之前从没设置过CurrentUser作用域它的默认值可能是Undefined。Undefined的意思是跟随更高优先级的作用域不是禁止。所以当你把它显式设成RemoteSigned后它就固定下来了不会再被LocalMachine的默认值影响。3.3 需要管理员权限的 LocalMachine 级修改如果你想让整台机器所有用户都生效或者你就是这台机器的管理员可以用Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine这条命令需要以管理员身份运行 PowerShell。执行后所有用户都会继承这个策略除非被CurrentUser或组策略覆盖。但我要提醒一句在多人共用的机器上改LocalMachine要谨慎。它会影响其他用户的脚本运行行为如果这台机器还跑着某些依赖严格策略的自动化任务可能会出问题。个人电脑随便改公司资产最好先问清楚。3.4 三种方案的对比与选择建议方案作用范围需要管理员持久性推荐场景Process当前窗口否关窗即失效临时跑一次CurrentUser当前用户否永久个人开发机首选LocalMachine全机器是永久单人多机或管理员选择逻辑很简单能不动系统就不动系统能只影响自己就不影响别人。所以优先级是 Process CurrentUser LocalMachine。只有在CurrentUser被组策略锁死、改不动的时候才考虑往上找。4. 改完还是报错排查链路完整复盘4.1 第一步确认策略到底改没改成功很多人敲完Set-ExecutionPolicy看到没报错就以为成了其实可能被静默覆盖。正确的验证方式是Get-ExecutionPolicy -List看输出里CurrentUser那一行是不是你设的值。如果显示的还是Restricted说明有更高优先级的作用域在压制。这时候要看MachinePolicy和UserPolicy两行——只要它们不是Undefined你的修改就无效。4.2 第二步检查是不是组策略锁死如果MachinePolicy或UserPolicy显示为Restricted那就是域控或本地组策略在管。这种情况下Set-ExecutionPolicy会直接报错或者执行了也不生效。排查路径是打开gpedit.msc专业版/企业版才有找到计算机配置 管理模板 Windows 组件 Windows PowerShell看打开脚本执行这项是不是被设成了已禁用。家庭版 Windows 没有gpedit.msc但组策略依然可能通过注册表下发。对应的注册表位置是HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell如果这里存在ExecutionPolicy键值那就是被策略锁了。普通用户没有权限改这个键需要联系 IT 管理员。4.3 第三步绕过策略的临时手段在策略被锁死、又急需跑命令的情况下有一个不改策略的绕过方式直接用-ExecutionPolicy Bypass参数启动一个新的 PowerShell 进程。powershell -ExecutionPolicy Bypass -Command npx create-react-app my-appBypass的意思是本次进程内不应用任何执行策略它比Unrestricted更彻底连提示都没有。这个参数只对当前启动的这个进程有效不会改变系统设置。注意Bypass是排查和应急手段不要把它写进日常脚本或快捷方式里长期使用。它绕过了所有脚本防护等于把安全默认值完全关掉。4.4 第四步确认是不是 npm.ps1 本身的问题还有一种情况策略已经改成RemoteSigned了但报错依然存在只是报错内容变了。比如提示npm.ps1文件损坏或路径不对。这时候要检查 Node.js 安装目录下的.ps1文件是否完整。正常安装的 Node.js 会在安装目录下生成npm.ps1、npx.ps1、npm.cmd、npx.cmd这几个文件。如果.ps1缺失PowerShell 找不到就会报别的错。可以这样验证Get-ChildItem C:\Program Files\nodejs\ -Filter *.ps1如果列表是空的说明安装不完整重装 Node.js 即可。如果文件在但报错可能是文件被杀毒软件隔离或损坏同样重装解决。4.5 排查流程速查表现象可能原因验证命令解决方向报禁止运行脚本策略为 RestrictedGet-ExecutionPolicy -List改 CurrentUser 为 RemoteSigned改了策略仍报错被组策略覆盖看 MachinePolicy 行联系 IT 或临时 Bypass报文件不存在.ps1 缺失Get-ChildItem *.ps1重装 Node.js报文件损坏被杀软隔离检查杀软隔离区恢复或重装换 CMD 就好了只是 PowerShell 问题在 CMD 里跑 npx说明策略是唯一原因5. 比改策略更省心的替代路径5.1 直接用 CMD 或 Git Bash 绕开 PowerShell最省事的办法其实是不跟 PowerShell 较劲。CMD 没有执行策略这回事在 CMD 里跑npx直接就能用。Git Bash 同理它用的是类 Unix 的 shell也不受 PowerShell 策略影响。如果你只是偶尔跑一下 npm 命令完全可以把默认终端从 PowerShell 换成 CMD。在 Windows Terminal 里改默认配置文件就行设置 启动 默认终端应用程序选命令提示符。或者在 VS Code 里改terminal.integrated.defaultProfile.windows为Command Prompt。这个方案的好处是零配置、零风险、不碰系统设置。坏处是你失去了 PowerShell 的很多便利功能比如对象管道、更好的补全。所以它适合我只想跑命令不想折腾终端的人。5.2 用 npx.cmd 显式调用如果你坚持用 PowerShell又不想改策略可以在命令后面显式加.cmdnpx.cmd create-react-app my-app这样 PowerShell 会去找npx.cmd而不是npx.ps1绕过了脚本拦截。同理npm.cmd、yarn.cmd都可以这么用。这个技巧在写 CI 脚本或批处理时特别有用因为它不依赖任何策略设置在任何 Windows 环境下都能跑。缺点是每次都要多敲四个字符长期用有点烦。5.3 在 VS Code 里配置默认终端VS Code 的集成终端默认走 PowerShell所以新手在 VS Code 里跑 npm 命令最容易撞上这个报错。除了改默认终端类型还有一个办法是在 VS Code 的settings.json里给 PowerShell 配置启动参数{ terminal.integrated.profiles.windows: { PowerShell: { source: PowerShell, args: [-ExecutionPolicy, Bypass] } } }这样每次 VS Code 启动 PowerShell 终端时都会带上Bypass参数等于给集成终端单独开了绿灯不影响系统其他部分。这个配置我个人用了很久实测很稳推荐给不想动系统策略的人。5.4 各方案适用性对比方案改动范围持久性副作用推荐指数改 CurrentUser 策略当前用户永久无五星换 CMD 终端终端配置永久失去 PS 功能四星显式加 .cmd单条命令无多敲字符三星VS Code Bypass编辑器内永久仅限 VS Code四星临时 Bypass 进程单次进程无无防护二星6. 几个容易忽略的连带问题6.1 执行策略和脚本签名是两回事有些人把执行策略改成AllSigned后发现连自己写的本地脚本都跑不了因为AllSigned要求所有脚本包括本地的都必须有数字签名。这时候要么改回RemoteSigned要么给自己的脚本签名。个人开发机没必要用AllSigned那是给企业受控环境准备的。6.2 中文路径和空格路径的坑Node.js 默认装在C:\Program Files\nodejs\这个路径里有空格。PowerShell 在处理带空格的路径时如果脚本内部没有正确加引号可能会解析出错。虽然执行策略问题跟路径空格没直接关系但如果你把 Node 装到了带中文或空格的目录后续可能遇到其他奇怪报错。建议 Node.js 装在纯英文无空格路径下比如C:\nodejs\。6.3 多版本 Node 管理器的策略冲突用 nvm-windows 这类版本管理器切换 Node 版本时每次切换都会重新生成 shim 文件。如果这些 shim 是.ps1格式同样会受执行策略影响。所以用了版本管理器的人更要把CurrentUser策略设成RemoteSigned否则每次切版本都可能触发报错。6.4 系统更新后策略被重置Windows 大版本更新有时会重置部分系统设置包括执行策略。如果你某天突然又看到这个报错先别怀疑 Node直接Get-ExecutionPolicy -List看一眼大概率是策略被改回去了。重新设一遍CurrentUser即可。6.5 远程桌面和虚拟机环境的特殊性在远程桌面或虚拟机里操作时执行策略可能继承宿主机的组策略设置。有些虚拟机模板默认就是Restricted而且CurrentUser作用域被锁。这种情况下优先用Process级临时修改或者直接用 CMD别在策略上死磕。7. 我踩过的几个真实坑第一次遇到这个报错时我的反应是重装 Node.js装了三遍报错一模一样。后来才意识到问题在 PowerShell 不在 Node。这个教训让我养成了一个习惯看到.ps1相关的报错先查执行策略别动 Node。第二个坑是改了LocalMachine却没生效。当时在一台公司电脑上用管理员权限改了LocalMachine为RemoteSignedGet-ExecutionPolicy显示也是RemoteSigned但跑 npx 还是报错。后来用-List一看MachinePolicy是Restricted组策略压着我改的LocalMachine根本不起作用。这个坑让我明白单看Get-ExecutionPolicy不够必须看-List的完整层级。第三个坑是Bypass用顺手了。有段时间我把所有 PowerShell 快捷方式都加上了-ExecutionPolicy Bypass图省事。后来意识到这等于把整台机器的脚本防护全关了任何下载来的脚本都能静默执行。赶紧改回RemoteSigned。Bypass 是应急工具不是日常配置。最后一个经验如果你经常在不同机器之间切换把设置策略的命令写成一个初始化脚本新机器上跑一次就行。我自己的初始化脚本里就有这么一行Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force-Force参数的作用是跳过确认提示适合写在自动化脚本里。这样每台新机器配置环境时这一步永远不会漏。