甘剑平你是不是也遇到过这个场景：在 Windows 上装完 Node.js，打开 PowerShell，敲下 npm -v，版本号没等到，先看到一大段红色报错：
powershell复制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
很多人的第一反应是 Node.js 没装好，于是卸载重装、改环境变量、去系统里翻文件，折腾半天问题毫无变化。实际上，这不是 npm 安装失败，也不是 PATH 配置有问题，而是 PowerShell 的“脚本运行权限错误”拦住了 npm 的 .ps1 包装脚本。这篇文章我会把这个问题的原理、排查步骤、解决方案和后续踩坑全部展开讲一遍，适合刚在 Windows 上配置 Node 环境、对 PowerShell 执行策略不熟的开发者参考。你不需要背命令，但我会尽量让你理解每条命令背后的理由，避免以后靠“瞎试”碰运气。
1. Node 安装过后，PowerShell 为什么会去执行 npm.ps1
1.1 一个 npm 命令，实际上对应了三种可执行形态
打开 Node.js 的安装目录，比如 C:\Program Files\nodejs\，你会看到三个和 npm 相关的文件：
npm：没有扩展名的 Shell 脚本，主要给 Git Bash、WSL、Unix-like 环境用的。npm.cmd：给 cmd.exe 和 Windows 批处理环境用的命令脚本。npm.ps1：给 PowerShell 用的包装脚本，内部会调用 Node.js 去执行npm-cli.js。
既然 Node.js 安装器已经把这三个文件都准备好了，为什么 PowerShell 不用 npm.cmd，偏偏去加载 npm.ps1？
这里要理解 PowerShell 的命令解析方式。你在 PowerShell 里输入 npm，它会优先在内存里找别名、函数、Cmdlet，找不到再去 PATH 环境变量对应的目录里找“可以被它调用的可执行文件”。和 cmd.exe 不同，PowerShell 会把 .ps1 脚本也当作一种可调用命令的来源，于是它能在 PATH 里同时看到 npm.cmd 和 npm.ps1。在不同操作系统和不同 PATH 顺序下，最终命中的对象不一定完全相同，但很多 Windows 环境中 PowerShell 会命中 npm.ps1。一旦命中 .ps1，执行策略就会介入了。
| 文件 | 由谁解释执行 | 使用场景 | 是否受 PowerShell 执行策略限制 |
|---|---|---|---|
npm |
sh / bash | Git Bash、WSL、类 Unix 环境 | 否 |
npm.cmd |
cmd.exe | cmd、批处理、传统命令行 | 否 |
npm.ps1 |
PowerShell | Windows PowerShell 5.1、PowerShell 7 | 是 |
1.2 PowerShell 不会把 .cmd 和 .ps1 当作一回事
很多在 cmd 下安装过 Node.js 的朋友会疑惑：我明明在 cmd 里执行 npm -v 是好的，怎么到 PowerShell 里就报错了？
原因就是 cmd.exe 和 PowerShell 对命令脚本的处理机制不同。cmd 会选择 npm.cmd 或者直接按批处理逻辑去执行包装命令，而 cmd/bat 文件不受 PowerShell ExecutionPolicy 限制。PowerShell 则不一样，它会把自己能识别的 .ps1 脚本纳入命令查找范围，而 .ps1 文件属于“脚本”，必须被 PowerShell 执行策略“审一遍”。当执行策略处于默认的 Restricted 状态时，任何 .ps1 脚本都不允许运行，于是你在 PowerShell 里敲 npm，系统刚找到 npm.ps1，还没执行就被拦下。
所以问题的核心很明确：不是 npm 本身出了故障，是 PowerShell 禁止运行 .ps1 这个“载体”。你从网上下载 Node.js 安装包、用安装器写入 PATH、这些都是正常的，真正卡住你的是脚本执行权限。
1.3 别把“脚本权限错误”和“命令找不到”混在一起
和这个报错经常一起出现的，还有另一类提示：
powershell复制npm : 无法将“npm”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。
这两种错误的原因完全不同。“无法识别”通常代表 PATH 环境变量里没有 Node.js 安装目录，或者你安装之后没有重新打开终端，导致新加入 PATH 没有生效。而“禁止运行脚本”代表 PATH 能找到 npm，只是 PowerShell 在决定执行 npm.ps1 时被策略拦住了。搞错这个区别，后续排查会非常浪费时间。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. PowerShell 执行策略的等级、作用域与优先级
2.1 五种常见的执行策略等级
PowerShell 的执行策略并不是“开”或者“关”那么简单，官方定义了多个级别。下表是我平时最常用到的解释：
| 策略 | 含义 | 什么时候可能用到 |
|---|---|---|
Restricted |
禁止运行任何 .ps1 脚本，单条命令可以执行 |
Windows 客户端默认常见状态 |
AllSigned |
所有脚本必须有数字签名才能运行 | 安全要求高的服务器或企业内部 |
RemoteSigned |
本地创建的脚本允许运行，从互联网下载的脚本需要有签名或先解除标记 | 开发环境最常用的折中方案 |
Unrestricted |
允许运行所有脚本，但运行从网上下载的未签名脚本时可能弹出提示 | 不建议日常使用 |
Bypass |
不做任何策略检查，脚本直接执行 | 临时操作、一次性脚本场景 |
另外还有一个 Undefined，意思是“未显式设置”。当某个作用域是 Undefined 时，PowerShell 会继续向它上一级作用域寻找可用策略；如果一路到默认值都没有配置，那最终就用系统默认策略，客户端机器常见就是 Restricted。
你可能听过“改成 Unrestricted 就全网畅通”的说法，但我不推荐。RemoteSigned 已经能解决 npm 引发的绝大部分问题，同时仍然会拦下一部分从互联网下载但没签名的 PowerShell 脚本，要比 Unrestricted 安全得多。
2.2 策略作用域和执行顺序
PowerShell 的执行策略不是只有一个值，它同时存在于多个“作用域”里，优先级从高到低是这样：
text复制MachinePolicy > UserPolicy > Process > CurrentUser > LocalMachine
MachinePolicy和UserPolicy通常由组策略（GPO）下发，普通用户很难改，优先级最高。Process只影响当前这一个 PowerShell 进程，关闭窗口就失效。CurrentUser只影响当前 Windows 用户，写入的是当前用户的注册表配置。LocalMachine影响整台机器所有用户，需要管理员权限才能改。
判断当前真正生效的策略，不要用“我上次改过什么”来自我猜测，直接运行：
powershell复制Get-ExecutionPolicy -List
输出大概长这样：
text复制 Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined
UserPolicy Undefined
Process Undefined
CurrentUser RemoteSigned
LocalMachine Restricted
这种情况下，真正生效的是 RemoteSigned，因为当前用户的优先级比本机策略高。如果 MachinePolicy 或 UserPolicy 里已经有值，那么就算你改了 CurrentUser 或 LocalMachine，也可能不起作用，因为高优先级策略会把低层级修改覆盖掉。
2.3 企业电脑为什么“改了也没用”
这种情况我在公司电脑上遇到过太多次。开发者的本机往往自己说了算，改一个 CurrentUser 就完事。但在企业域环境里，IT 部门可以通过组策略把执行策略固定在 Restricted，并且不让你通过 Set-ExecutionPolicy 覆盖。
如果你执行完命令后发现被拒绝，会看到类似的提示：
text复制Set-ExecutionPolicy : 对注册表项“HKEY_LOCAL_MACHINE\...SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell”的更改被组策略覆盖，请与管理员联系。
这不是命令写错了，是策略层级比你更高。此时与其硬对抗，不如用 npm.cmd 这类不带 .ps1 的调用方式，或者找管理员确认是否能放开本机策略。
3. 修改前先做三次诊断：把策略和文件位置看全
3.1 第一步：确认当前生效的策略是什么
不要一看到报错就急着执行修复命令。先看当前策略，记录当时的现场状态，后面如果问题再次出现，你能判断到底是被哪个作用域卡住的。
powershell复制Get-ExecutionPolicy
如果返回 Restricted，那基本可以确定执行策略就是拦路者。如果想看完整链路，用：
powershell复制Get-ExecutionPolicy -List
这一步还能帮你判断：LocalMachine 是 Restricted，但 CurrentUser 是否为 Undefined。如果当前用户作用域是 Undefined，那改当前用户作用域就会非常干净，不会影响其他用户。
3.2 第二步：定位 PowerShell 找到的 npm 脚本路径
我们可以用 PowerShell 自带的命令确认 npm 到底被解释成什么文件：
powershell复制Get-Command npm -All
输出会列出多个同名命令/文件，比如一个可能是 npm.cmd，另一个可能是 npm.ps1。通过这个输出，你能知道你机器上 PATH 包含的 Node 安装目录是哪一条，避免明明改好了路径却对着另一个旧版本 Node 目录操作。
如果只是想快速看 PATH 上的 npm 来自哪里，也可以用：
powershell复制where.exe npm
在 Windows 上，where.exe 会把 PATH 里所有可能候选的路径列出来，包括 .cmd、.ps1 文件。看到结果后，你再去检查对应路径是否存在：
powershell复制Test-Path "C:\Program Files\nodejs\npm.ps1"
如果返回 True，说明这个文件在，拦截就发生在策略层，而不是文件层。
3.3 第三步：区分“官方安装器版 Node”和“nvm 管理版 Node”
Node.js 的安装方式不是只有一种。官方提供的 Windows 安装 MSI 一般会把 Node 装到 C:\Program Files\nodejs\，而如果用 nvm-windows 这类版本管理器，实际 Node 目录会存在于 %APPDATA%\nvm\ 或你指定的路径，同时生成一个符号链接目录。无论安装方式怎么变，npm.ps1 的报错本质是一样的，修改执行策略也同理，但你可能需要根据实际路径去检查文件是否完整。
有一种情况需要注意：如果你切换了 Node 版本，但 PowerShell 仍旧指向旧的符号链接，就会导致执行一个老版本的 npm.ps1。这不会直接造成“禁止运行脚本”，但会让你在排查时产生困惑。建议切换 Node 版本后重新打开终端，或者至少运行 Get-Command npm 确认路径。
如果报错不是“禁止运行脚本”，而是“无法将 npm 项识别为命令”，那就先不要改执行策略，优先去环境变量里检查 PATH 是否真的包含 Node 目录，然后重新打开终端再试。
4. 解决权限错误最快的三条路线，以及我为什么不推荐 Unrestricted
4.1 不想动任何策略：直接用 npm.cmd
如果是在别人的电脑上临时跑一下 npm，不方便修改系统设置，最简单的办法是绕过 .ps1，直接调用 npm 的 cmd 版：
powershell复制npm.cmd -v
这样 PowerShell 会执行 npm.cmd，cmd/bat 脚本不受 ExecutionPolicy 限制，所以可以正常运行。同理，如果 npx 也报同样错误，可以试：
powershell复制npx.cmd -v
代价也很明显，以后每次敲命令都要手动加 .cmd 后缀，非常别扭。如果你只是在临时环境里验证一下 npm 是否装好，这个方式够用；但长期开发肯定不适合。
还可以通过 PowerShell 配置一个别名，把常用命令映射到 .cmd 版本。不过我不太建议新手一开始就搞别名，因为你会在网上看到各种写法，一旦和你本机的 PowerShell Profile 冲突，排查起来会更麻烦。先理解问题，再谈优化。
4.2 只想当前会话临时放行：Process 作用域
如果你已经打开了 PowerShell，只想在这个窗口里允许脚本运行，不需要永久修改系统，可以执行：
powershell复制Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process
这里选择 RemoteSigned 而不是 Bypass，是一个更克制也更安全的临时策略。命令执行完，当前 PowerShell 窗口立刻获得运行本地 npm.ps1 的能力，关掉窗口后不留痕迹。
如果连“本地脚本是否需要验证来自互联网”也不想管，只希望不受任何限制地执行，可以用：
powershell复制Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process
但我个人只在运行来路明确、临时需要清理现场时用 Bypass，平时保持 RemoteSigned 习惯就够。
4.3 永久解决且风险可控：设置 CurrentUser 为 RemoteSigned
对于绝大多数个人开发电脑，我的推荐是直接把当前用户的执行策略设为 RemoteSigned。这个方案的好处是：
- 不需要管理员权限，普通用户在自己账户下就能执行。
- 不会影响这台机器上的其他用户。
- 本机创建的
.ps1文件可以运行，包括 npm 的包装脚本。 - 从互联网下载又没有签名的脚本依然会被阻止，保留了一道重要防线。
执行命令如下：
powershell复制Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
PowerShell 会问你是否确认，输入 Y 或使用 -Force 参数跳过确认：
powershell复制Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force
然后重新打开一个终端，再执行：
powershell复制npm -v
一般情况下就能正常输出版本号了。此后 npx、corepack 这类同样附带 .ps1 包装器的命令也会一并受益，因为它们遇到的都是同一个策略问题。
4.4 管理员场景和组策略锁定场景：LocalMachine 或启动参数
如果这台机器的所有用户都需要用 npm，管理员可以在管理员权限的 PowerShell 里执行：
powershell复制Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine -Force
对于某些自动化脚本，比如 CI 流水线或者需要在命令行里临时执行 PowerShell 脚本的运维场景，可以用启动参数绕过。这个参数不会修改注册表，只对新建的 PowerShell 进程生效：
powershell复制powershell.exe -NoProfile -ExecutionPolicy Bypass -Command "npm -v"
在 PowerShell 7 中，可执行文件名变成了 pwsh.exe：
powershell复制pwsh.exe -NoProfile -ExecutionPolicy Bypass -Command "npm -v"
这种方式适合一次性任务，在开发机日常操作中没有必要，因为每次都嵌套一个 PowerShell 进程会让命令变长，也容易让终端魔法看起来像“记住了技巧却没理解原理”。
4.5 为什么我不建议直接 Unrestricted
很多教程会让你把执行策略设置成 Unrestricted，敲一行命令就一劳永逸。这样确实能解决报错，但副作用是把整个 PowerShell 环境的脚本防线全部打开。如果你在某天不小心执行了一个从网上下载的恶意 PowerShell 脚本，后果会比其他环境更严重。
RemoteSigned 和 Unrestricted 对本地开发工具的差别很小，因为 npm 的 .ps1 是 Node.js 安装器在本地生成的，不会被判定为“来自互联网”，在 RemoteSigned 下可以正常运行。所以我更愿意少一点权限，多一点安全余量。
5. 改完策略还报错？这些隐藏环节比权限更容易忽略
5.1 终端缓存和 IDE 集成终端需要重启
执行完 Set-ExecutionPolicy 之后，如果你的 VS Code 集成终端依然报错，先不要怀疑命令没生效。VS Code 的集成终端和 Windows Terminal 都可能保留着老的 PowerShell 进程，旧进程里读取到的策略还是修改前的值。
建议先关掉所有 PowerShell 标签页，重新打开一个终端窗口，再执行 npm -v。如果 VS Code 里还不生效，直接 Ctrl+Shift+P，选择重新加载窗口。这个步骤看起来很简单，但排障时很容易被忽略，因为你会以为是策略没改成功。
5.2 从互联网下载的脚本可能被“区域标识”拦截
RemoteSigned 对本地脚本非常宽松，但有一个例外：你从浏览器下载下来的 .ps1 文件，Windows 可能给它打上了“来自互联网”的标记，也就是 Zone.Identifier。这种情况下即使你的执行策略已经是 RemoteSigned，文件依然会被拦下来。
可以用 Unblock-File 解除标记：
powershell复制Unblock-File .\your-script.ps1
如果你想确认文件是否被标记，可以在命令行里查看文件的 Zone.Identifier：
powershell复制Get-Item .\your-script.ps1 -Stream Zone.Identifier
如果返回结果为空，说明没有这个标记；如果返回了一串内容，就说明它确实被 Windows 判定为远程文件。很多开发者把问题全都推给执行策略，其实真正卡住下载脚本的另有其因。
5.3 npx 以及其他 Node 全局命令可能继续报错
npm 修好之后，如果你还装了 npx、yarn、pnpm、corepack，那么这些命令也可能以相同的 .ps1 方式工作。因为它们都装在 Node 的目录里，也同样提供 .ps1 包装器。当你把 CurrentUser 执行策略设置为 RemoteSigned 后，这些命令通常也能恢复。
如果仍然有某一个单独的命令报错，可以单独找到对应目录，检查它是否还存在 .ps1 文件。例如：
powershell复制Get-Command npx -All
然后看它的具体路径。如果文件丢失或损坏，那问题就从执行策略转移到了 Node 安装完整性上。
5.4 PowerShell 7 和 Windows PowerShell 5.1 之间的差异
你的电脑上可能同时存在两个 PowerShell：
- Windows PowerShell 5.1，可执行文件名是
powershell.exe。 - PowerShell 7，基于 .NET，可执行文件名是
pwsh.exe。
这两个版本在 Windows 上会查询同一套执行策略配置，但进程不会被对方自动继承。也就是说你在 powershell.exe 里手动设置了 Process 作用域，再启动 pwsh.exe，新进程的 Process 作用域仍然是 Undefined，需要重新读取注册表或策略。
如果你平时既用 Windows PowerShell 5.1 又用 PowerShell 7，建议把相关策略设置在 CurrentUser 或 LocalMachine 这种持久层，而不是只在某个进程里临时放行。
5.5 杀毒软件或终端侧的安全插件也可能拦截脚本
有极少数情况，PowerShell 执行策略已经是 RemoteSigned，npm 也仍然被拦截。我不是说要让你怀疑所有安全工具，但团队里开发机的终端的脚本扫描策略如果过于激进，同样会在运行时阻止可疑脚本。判断方式很简单：用系统自带的 PowerShell 跑一次 npm -v，如果系统 PowerShell 正常，而你的第三方终端工具异常，那问题大概率不在执行策略，而在终端软件或插件侧。
同样道理，如果你用了一些企业端安全软件对 PowerShell 做行为审计，那么它也可能阻止 npm.ps1 的启动过程。这时候光靠本机执行策略可能不够，需要从安全软件的 exclusions 或策略配置里给 Node 目录放行。
6. 从解决 npm 到理解 PowerShell 脚本执行边界，我留下的一点习惯
每次遇到这种“一条命令搞不定”的环境问题，我都会顺手把现场信息保存下来，而不是随手改完就翻篇。至少记录三样东西：报错原文、Get-ExecutionPolicy -List 的结果、npm 安装路径。下次再出现同类问题，不用重新猜原因。
我自己的开发机上，执行策略长期保持在 CurrentUser 为 RemoteSigned，没有给 LocalMachine 放开任何权限。遇到临时脚本时，优先用 Process 作用域去放行；遇到下载下来的脚本文件，先看是不是被 Zone.Identifier 标记，再考虑处理方式。被“禁止运行脚本”拦了这么多次之后，我反而觉得这个策略设计是有意义的——至少每次要运行新脚本之前，Windows 都会强制我确认“这个东西该不该跑”。
如果你的 npm 现在能正常输出版本号了，还可以继续往下检查一条：尝试执行 npx -v，如果有问题，按同样的思路处理；如果一切正常，那和你平时使用 npm 过程中的绝大多数命令相关的问题，大概率已经被这个参数解决了。不要轻易为了省事把执行策略调到 Bypass 或 Unrestricted，那相当于给自己埋了个更隐蔽但不自知的雷。