写这篇东西的起因很简单：后台隔三差五就有人发来同一张报错截图，内容是“npm : 无法加载文件 D:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本”。别看这个问题出现频率极高，绝大多数人第一反应都是重装Node.js，结果装了三遍还是红彤彤一片。今天我把这个问题的来龙去脉完整拆一遍，核心结论先放这：这不是npm坏了，也不是Node.js装错了，是你的PowerShell默认禁止运行脚本，把npm的启动入口给拦下来了。你会怎么修、为什么这样修、修完还会碰到哪些衍生问题，这篇全部讲透。
1. 先还原报错现场：PowerShell把npm.ps1拦在了门外
1.1 报错长什么样：一行行拆给你看
假设你在Windows上装好了Node.js，兴冲冲打开PowerShell，敲下npm -v，屏幕大概会变成这样：
npm : 无法加载文件 C:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本。有关详细信息， 请参阅 https:/go.microsoft.com/fwlink/?LinkID=135170 中的 about_Execution_Policies。 所在位置 行:1 字符: 1 + npm -v + ~~~ + CategoryInfo : SecurityError + FullyQualifiedErrorId : UnauthorizedAccess这段红色报错里有几个关键信息值得逐行看：
- “无法加载文件 C:\Program Files\nodejs\npm.ps1”：PowerShell明确告诉你，它想执行的是这个路径下的
npm.ps1，不是别的什么东西。 - “因为在此系统上禁止运行脚本”：这就是全部原因——当前PowerShell执行策略（Execution Policy）不允许运行.ps1脚本。
- “有关详细信息，请参阅 about_Execution_Policies”：微软已经把解决方案写在了官方帮助文档里，本质上就是教你去改执行策略。
- “SecurityError”和“UnauthorizedAccess”：这是错误的类别和ID，你可以理解为PowerShell把这次拦截定性为“安全问题”，而不是“找不到命令”。
不管你的Node.js装在D盘还是C盘，只要报错文字里出现“因为在此系统上禁止运行脚本”，原因都是同一个，你不需要再去怀疑安装包有问题。
1.2 这不是npm坏了，而是PowerShell先动手了
很多新手在这里会陷入一个误区：以为是npm没装成功，于是卸载重装、换版本、改PATH，折腾一圈回来，报错纹丝不动。原因很简单——问题根本不出在npm身上。
npm在Windows上的启动方式不止一种。当你在PowerShell窗口里输入npm时，PowerShell优先找到的是npm.ps1这个PowerShell脚本文件。而PowerShell出于系统默认的安全策略，禁止运行任何.ps1脚本，所以它在这个入口处就把npm拦下了，压根没轮到真正的npm主程序动手。
换句话说，npm本身完好无损地躺在安装目录里，是PowerShell不让你碰它。你只要让PowerShell对本地脚本“放行”，问题立刻消失。这也是为什么很多人把上报错挂到网上之后，底下评论清一色只提一个命令：Set-ExecutionPolicy RemoteSigned。
1.3 同类报错傻傻分不清：三张脸对照一下
跟“npm跑不起来”相关的报错有好几种，很多人把下面的情况混为一谈，结果用错了修复方向。我列个最常见的对照表：
| 报错内容 | 根因 | 修复方向 |
|---|---|---|
| npm : 无法加载文件 npm.ps1，因为在此系统上禁止运行脚本 | PowerShell执行策略禁止运行.ps1 | 修改ExecutionPolicy |
| 无法将“npm”项识别为 cmdlet、函数、脚本文件或可运行程序的名称 | PATH环境变量没配好，找不到npm命令 | 检查并修复环境变量 |
| “npm” 不是内部或外部命令，也不是可运行的程序或批处理文件 | 同上，这是CMD下的同一种情况 | 检查并修复环境变量 |
我见过太多人拿着第一种报错去百度“npm不是内部或外部命令”，然后对着环境变量改了半天。如果你看到的关键词是“禁止运行脚本”，就请回到本文的路径上来，别走岔了。
2. 为什么偏偏是.ps1：npm入口文件与PowerShell执行策略的来龙去脉
2.1 Windows里npm的三件套入口
Windows版的Node.js安装包会在安装目录（比如C:\Program Files\nodejs\）下放三个npm入口文件：
npm：无扩展名的Shell脚本，主要在Git Bash、Cygwin这类Unix风格环境下使用。npm.cmd：CMD批处理脚本，你在命令提示符（cmd.exe）里敲npm时，实际执行的是它。npm.ps1：PowerShell脚本，你在PowerShell里敲npm时，实际优先命中的是它。
这三兄弟各自服务于不同的Shell环境，功能完全一致，区别只是“语言”不同。正因为有你熟悉的显示器背后这一层设计，才出现了“cmd里能跑npm，PowerShell里却报禁止运行脚本”的奇特现象。
2.2 PowerShell的命令发现顺序：为什么先摸到.ps1
Windows命令提示符执行外部命令时，会按照PATHEXT环境变量中定义的扩展名顺序去找可执行文件，比如.COM、.EXE、.BAT、.CMD，但一般不会主动去碰.PS1。所以在cmd里敲npm，它找到的是npm.cmd。
PowerShell则不一样。它在解析命令时有一套优先级：Alias（别名）> Function（函数）> Cmdlet（内置命令）> 外部可执行文件/脚本。当走到“外部可执行文件/脚本”这一步时，PowerShell会优先匹配.ps1脚本文件，这就导致了在PowerShell里执行npm时，实际要跑的是npm.ps1。
你可以在PowerShell里跑一句命令验证：
Get-Command npm | Format-List Name, Definition, Path出来的结果里Path一栏大概率指向的就是npm.ps1。看到这个文件路径，你就明白为什么“禁用脚本”这个策略会让你寸步难行了。
2.3 ExecutionPolicy是什么，为什么默认拦人
PowerShell的功能非常强大，它能删文件、改注册表、下载执行远程脚本、批量控制整个系统。这么强大的东西一旦被恶意脚本利用，破坏力是灾难级的。所以微软给PowerShell设计了执行策略（Execution Policy），本质是一道安全闸门，控制哪些.ps1脚本可以运行。
常见的策略级别有五个，我给你整理成表格：
| 策略级别 | 行为说明 | 实际安全性 |
|---|---|---|
| Restricted | 禁止运行任何.ps1脚本，本地写的不行，下载的更不行 | 最高，但也最不方便 |
| AllSigned | 所有脚本必须有可信签名才能运行，本地没签名的也不行 | 高，但自己写脚本也得折腾签名 |
| RemoteSigned | 本地创建的脚本放行，从Internet下载的脚本必须签名 | 推荐，平衡了安全与便利 |
| Unrestricted | 允许运行所有脚本，外部下载脚本运行时会有警告提示 | 偏低，容易误运行恶意脚本 |
| Bypass | 全部放行，不警告不签名，等同关闭此功能 | 极低，只建议临时用一次 |
Windows桌面系统的默认策略就是Restricted，也就是“什么.ps1都不准跑”。这个默认策略不是拍脑袋定的，而是为了保证系统安全，防止用户稀里糊涂就双击运行了一个来路不明的PowerShell脚本。可问题是，它把npm这种正经工具也一并拦了。就像门禁系统把所有访客都拦在门外，连给你送快递的也要搜个底朝天。
2.4 一句话理解安全边界
如果把系统安全比作小区安保，Restricted就是“任何人都不让进”；AllSigned是“所有人都要出示盖章的身份证”，本地住户也不例外；RemoteSigned是“本小区住户随意进出，访客必须登记”；Unrestricted是“谁都能进，保安最多口头问一句”；Bypass等于直接把门禁拆了。
npm是我们作为开发者自己安装到本地的正经程序，它不是从网上下载后即时运行的陌生脚本，所以把它所在目录的本地脚本放行，并不会引入明显的安全风险。这正是RemoteSigned能成为主流解法的原因。
3. 一次性解法：把执行策略改成RemoteSigned并验证到底
3.1 为什么选RemoteSigned而不是其他
在众多策略里，我个人强烈推荐RemoteSigned，原因有三个：
第一，它能彻底解决npm的问题，以后npm -v、npm install、npm run build、npm publish等所有命令都不会再被PowerShell拦截。
第二，它保留了“下载脚本必须被签名”的安全门槛，比Unrestricted和Bypass稳妥太多。日常开发里，你仍然会受到保护，不会随便放行网上下载的恶意脚本。
第三，它的操作范围可以精确控制到“当前用户”，不用让系统管理员为你额外放开机器级别的策略，也不影响其他用户。
这三个理由合起来就是：好用、够稳、影响面小。单位电脑、个人电脑都适用。
3.2 一步步操作：改策略、确认、验证
操作流程非常简单，就是三条命令加一次确认。打开PowerShell窗口，按顺序执行：
第一步，先看当前策略到底是什么状态：
Get-ExecutionPolicy -List这条命令会列出各个作用域的当前策略。你会看到一连串Undefined和一个Restricted，这就是为什么npm跑不起来的原因。
第二步，执行修改：
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser执行后PowerShell会弹出一段说明文字，问你是否要更改执行策略，输入Y回车确认。
第三步，验证是否生效：
Get-ExecutionPolicy -List npm -v前一条命令会看到CurrentUser一栏变成了RemoteSigned，后一条命令如果能正常打印出npm版本号，说明问题解决，你可以接着去装包干活了。
3.3 一条条拆解这条核心命令
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser看着长，拆开其实很好懂：
Set-ExecutionPolicy是PowerShell内置命令，负责设置执行策略。-ExecutionPolicy RemoteSigned指定策略内容为RemoteSigned。-Scope CurrentUser指定这个设置只对当前用户生效。
关键就在Scope参数。你完全可以选择-Scope LocalMachine，让整台机器所有用户都生效，但那样需要以管理员身份运行PowerShell，否则会报错。而CurrentUser不需要管理员权限，改完只影响当前登录用户，安全面小，对大多数开发者来说完全够用。
3.4 不想改策略的临时救急办法
有些场景下你不想动执行策略，比如在公司统一管控的电脑上，你无权修改任何策略，或者你只是临时跑一条npm命令，不想为此改全局配置。这种时候有几个临时绕过方案：
- 在PowerShell当前会话内临时放开：
Set-ExecutionPolicy Bypass -Scope Process。这里Process只对当前这个PowerShell窗口有效，一关窗口就恢复原样。 - 直接用CMD执行：按
Win + R输入cmd回车，在命令提示符里执行npm命令，走的是npm.cmd入口，根本不涉及脚本策略。 - 用Git Bash：如果你装了Git for Windows，在Git Bash里执行npm同样不受PowerShell策略影响。
这三个办法都属于应急方案，跑临时命令够了，但不建议长期依赖。原因很简单：每个新开的PowerShell窗口都要重复操作，而且你随时可能忘掉这回事，不到半小时又回到原地报错。
4. 改了策略依然翻车：从环境变量到终端配置的完整排查链
4.1 最容易误判的：“npm不是内部或外部命令”是另一回事
很多人在改完执行策略后依然跑不起npm，然后跑回来问我：“我明明按你说的改了RemoteSigned，怎么还是不行？”我一看截图，报错根本不一样，是“npm不是内部或外部命令”。
这里必须掰开揉碎讲一遍：这类报错跟PowerShell执行策略没有任何关系，它的根因是系统找不到npm命令。此时你要排查的是PATH环境变量，而不是执行策略。在PowerShell里你可以执行：
echo $env:Path Get-Command node Get-Command npm如果node有输出而npm没有，那多半是Node.js安装不完整或PATH配置丢失。在CMD里则可以用：
where node where npm如果这两条命令输出的路径不一致，或者干脆查不到npm，你就需要去“系统属性 -> 环境变量”里检查Path是否包含了Node.js安装目录，比如C:\Program Files\nodejs\。没有就手动补上，补完重启终端再测。
4.2 按优先级排出排查顺序
如果你确认自己的报错是“禁止运行脚本”，且已经执行了Set-ExecutionPolicy，却依然报错，请按下面的顺序逐个排查：
| 现象 | 可能原因 | 优先检查项 |
|---|---|---|
| 改完策略后npm还是报禁止脚本 | 终端没重启，新策略没被重新加载 | 关掉PowerShell窗口重新打开 |
| Set-ExecutionPolicy执行时报“策略已被组策略覆盖” | 当前电脑受组织统一策略管理 | 确认是否公司电脑，联系管理员放开 |
| 当前用户改成RemoteSigned后其他用户仍报错 | 你改的Scope只覆盖当前用户 | 检查该用户自己的CurrentUser作用域 |
| 双开不同终端（PowerShell、VSCode终端）表现不一致 | 每个终端进程独立加载策略 | 统一重启所有终端再验证 |
已经改了CurrentUser但Get-ExecutionPolicy还是Restricted | 还有更高优先级作用域压制 | 看下一小节的策略叠加规则 |
注意表格里“受组织统一策略管理”的情况。公司统一管控的电脑往往通过组策略锁死了执行策略，你在命令行里怎么改都会被更高优先级的策略覆盖。这种机器不是技术能解决的，需要走正常工作流程申请放开。这不是你代码写错了，也不是命令敲错了。
4.3 VSCode内置终端不生效的坑
不少人用的是VSCode，改完PowerShell后兴冲冲在VSCode内置终端里敲npm -v，结果依然报错。原因很简单：VSCode的内置终端默认加载的是PowerShell，但它启动时读取的是当时已经存在的执行策略配置。你在外部改完策略之后，VSCode里那个老终端进程还保留着改之前的上下文，没有重新读取策略。
解决办法一个是重启VSCode窗口，一个是手动关闭再新建终端，又或者执行一下：
. $PROFILE但最省事的就是：改完策略后，把所有终端都关掉重开。这个细节看着小，却是“改了半天没反应”的最常见翻车点。
4.4 确认生效的命令和策略叠加规则
PowerShell的执行策略有多个作用域，按优先级从高到低依次是：
MachinePolicy：机器级组策略，优先级最高。UserPolicy：用户级组策略。Process：当前进程，临时设置用的。CurrentUser：当前用户，我们推荐修改的目标。LocalMachine：本机所有用户。
你的策略最终生效结果，由其中优先级最高的那一个决定。所以当你执行Get-ExecutionPolicy -List看到下面这种输出时：
Scope ExecutionPolicy ----- -------------- MachinePolicy Undefined UserPolicy Undefined Process Undefined CurrentUser RemoteSigned LocalMachine Restricted只要CurrentUser已经是RemoteSigned，并且更高优先级的作用域都是Undefined，那当前用户的PowerShell就会按RemoteSigned规则执行。此时npm -v如果还报错，请回到4.3检查终端进程是否重新加载了。
5. 报错解决后马上会撞上的三个高频坑
5.1 全局CLI集体罢工：vue、pnpm都跟npm一个命
执行策略解决之后，你的npm本体能正常跑了，但要注意，你通过npm全局安装的那些命令行工具——比如vue、pnpm、yarn、@tarojs/cli——它们的启动机制跟npm一样，全都有对应的.ps1入口。你之后在某天用着用着就会发现某个全局命令又报出同样的“禁止运行脚本”，千万别慌，这还是在吃老本，同一个根因。
解决办法跟前面完全一致：确认当前用户策略是不是RemoteSigned，是的话重启那个报错的终端即可；如果还没改过，补齐第三步的命令即可。一个策略修好了，全机器所有npm系CLI工具都跟着受益。
5.2 装包速度让人抓狂：换国内镜像源的正确姿势
脚本问题解决后，你很快会进入新的阶段：发现npm install慢得像在下载整个世界。大多数包能装上，但速度让人崩溃。这是因为默认官方源registry.npmjs.org的访问质量对国内网络并不友好。换国内镜像源是目前最直接有效的提速方式。
两条命令搞定：
npm config get registry npm config set registry https://registry.npmmirror.com第一条先看看你现在用的是哪个源，第二条把源切到阿里云维护的国内镜像。也可以安装nrm来管理多个源，想看当前源和切换源都更直观：
npm install -g nrm nrm ls nrm use npm nrm use taobao这里有个经验之谈：不要贪图方便去用cnpm。cnpm install虽然快，但在处理某些依赖的版本对齐和原生模块时，偶尔会出现组文件不完整或二次安装才能用的问题。优先考虑把npm官方源的地址换成国内镜像，这样既能享受提速，又尽量保留官方npm的行为特性，碰到问题更好排查。
5.3 装包时ERESOLVE和node-sass两堵墙
镜像源换好了，再往后装包还会遇到两个高频报错，分别是npm warn ERESOLVE overriding peer dependency和node-sass装不上。
ERESOLVE overriding peer dependency，本质是peerDependencies（同伴依赖）版本冲突。也就是你要装的那个包要求环境里必须存在某个特定版本范围的另一包，但当前项目却装了一个不符合要求的版本。npm严格校验peer依赖后拒绝继续安装。多数场景下用--legacy-peer-deps可以绕过这种校验继续安装：
npm install --legacy-peer-deps但注意，这只是跳过校验，不是真正的版本对齐。如果你是项目负责人，建议优先手动排查冲突的包版本，把互相冲突的依赖升级到能互相兼容的版本。如果只是临时跑个工具，--legacy-peer-deps倒是够用。
node-sass装不上则是另一个经典难题。node-sass是dart-sass的C++实现版本，需要针对特定Node版本重新编译原生二进制，因此它对Node版本非常敏感。Node版本和node-sass版本对不上时会直接编译失败。最好的解法是升级到sass包（纯dart-sass实现，不再依赖原生编译）：
npm uninstall node-sass npm install -D sass如果你的项目老到必须用node-sass，那就老老实实去查官方版本对应表，把Node版本调整到匹配范围内再装。
这两堵墙在PowerShell脚本问题解决之后，会成为你新的拦路虎。我已经见过太多开发者在同一个项目里依次撞上这三道坎：先被脚本策略卡住，再被镜像速度折磨，最后绊倒在依赖冲突上。这篇的流程走完一遍，你等于提前把这些路上的坑全填平了。
我的个人习惯是，新机器装完Node.js之后，第一件事就是把执行策略设为RemoteSigned、镜像源切到国内镜像，然后顺手装一个sass替代掉各项目里残留的node-sass依赖项。这一套组合拳做完，后面开发的日子清净太多。如果你现在正卡在某一步，按上面的顺序走，一般两分钟就能把npm重新捞回正常状态。
