1. 报错原文解读PowerShell的安全检查拦下了npm.ps11.1 未对文件进行数字签名在Windows上到底意味着什么很多刚在Windows上接触Node.js的人第一次看到这个提示都会有点懵未对文件 D:\node-v24.14.0-win-x64\node-v24.14.0-win-x64\npm.ps1 进行数字签名。无法在此系统上运行该脚本。这句话拆开看其实不复杂。Windows里给代码签名用的是一套叫Authenticode的技术发布者用自己的数字证书对文件做签名系统检查文件有没有被篡改过、发布者是谁、证书是否可信。一个脚本文件只要没带这个签名PowerShell就会把它当成身份不明的程序看待。npm.ps1就是这样一个身份不明的脚本。它是npm在PowerShell环境下的启动入口装在Node.js目录里但官方解锁安装包的时候并没有给这个包装脚本做数字签名。于是PowerShell默认的保守策略——Restricted——直接把它拦在了门外。说白了这不是Node装坏了也不是npm损坏了纯粹是PowerShell的安检门太严把没带身份证的本地脚本给拦住了。1.2 为什么偏偏是npm.ps1被拦而不是npm.cmd同一个目录里其实还有npm和npm.cmd这两个文件凭什么就npm.ps1报错原因在于终端环境不一样。你在CMD或者Windows Terminal里打开的是Command Prompt时输入npm系统找的是npm.cmdCMD只会按自己的规则执行批处理不管签名的事。但你在PowerShell里输入npm时PowerShell会优先识别到npm.ps1——PowerShell对.ps1脚本有特殊的执行策略校验没有签名就直接拒绝。所以你经常会看到这样的场景同一个npm命令在CMD里好端端的切到PowerShell就报未进行数字签名。这不是npm的问题而是PowerShell的脚本执行策略在起作用。后面我给的几个解决方案本质上都是在绕开或者调整这道安全检查。2. 动手之前先看清三件事目录结构、环境变量和执行策略2.1 目录里那个套娃路径很可能是个隐患注意看报错里的路径D:\node-v24.14.0-win-x64\node-v24.14.0-win-x64\npm.ps1这里出现了两层node-v24.14.0-win-x64。这种情况在手动解压官方zip包时非常常见——下载的压缩包里本来就有一个node-v24.14.0-win-x64文件夹解压的时候你又习惯性地新建了同名文件夹结果就变成套娃了。套娃路径本身不致命只要环境变量指向最里层的目录npm照样能运行。但问题在于很多人解压完直接把外层目录写进系统PATH然后发现node -v能用、npm却找不到或者反过来。而且这种长路径在后续配置全局命令、调试问题时会带来很多不必要的麻烦。我的建议是解压后干脆整理成简短的路径比如D:\nodejs\或者D:\node-v24.14.0-win-x64\然后把环境变量PATH指向这个单层目录。这样不管以后是手动升级Node还是配合nvm使用路径清晰排查问题快很多。2.2 用三条命令确认Node和npm的当前状态在动手改任何设置之前先打开PowerShell确认环境状态。就三条命令node -v npm -v Get-ExecutionPolicy -List如果node -v能正常输出版本号说明Node本身没问题。如果npm -v直接报未对文件...进行数字签名说明不是环境变量问题而是纯执行策略问题。如果node -v这一步就已经提示找不到命令了那先回头检查环境变量PATH把node.exe所在目录加进去再继续往下看。Get-ExecutionPolicy -List这条命令输出的是一张策略列表后面第三部分我会详细讲怎么看这里只需要先确认一下CurrentUser和LocalMachine两列的值是什么。如果都是Undefined或者Restricted那基本可以断定是执行策略在拦截。2.3 执行策略的分级机制LocalMachine、CurrentUser、ProcessPowerShell的执行策略不是一杆子打死的它分了六个作用范围优先级由高到低分别是MachinePolicy组策略配置最优先UserPolicy用户组策略配置Process当前进程临时策略CurrentUser当前用户策略LocalMachine本机全局策略Undefined未设置系统的默认状态通常是Restricted也就是禁止任何脚本运行。Set-ExecutionPolicy命令默认修改的是LocalMachine这个范围而LocalMachine的优先级低于CurrentUser。所以在某些情况下你明明执行了Set-ExecutionPolicy RemoteSigned却没生效原因很可能是范围选错了或者组策略把MachinePolicy锁到了更严格的值。理解了这层分级机制你再看网上各种解决方案时就不会被绕晕。最稳妥的开发机策略其实是修改CurrentUser范围既避免了管理员权限问题又不会影响到系统全局的其它脚本。3. 三类解决方案与实操细节临时绕过、策略调整、换终端3.1 方案一给当前PowerShell会话临时免检Process级别如果你只是想赶紧跑一个npm命令不想动任何系统设置可以在当前PowerShell窗口里执行Set-ExecutionPolicy -Scope Process Bypass这条命令把执行策略临时改成Bypass但作用范围只限当前这个窗口。关掉窗口重开策略就恢复了。实测下来这个方案非常适合应急——比如你只想执行一次npm install或者临时跑个脚手架改完这次就够了。需要注意一点Process级别的Bypass只对当前会话生效如果你再开一个新的PowerShell窗口还是会报同样的错。所以应急可以但如果你要在这台机器上长期做Node开发还是要依赖后面的方案二。3.2 方案二把当前用户的执行策略调整为RemoteSigned这是我最推荐的一种做法也是网上解决这个报错的主流方式。在PowerShell里执行Set-ExecutionPolicy -Scope CurrentUser RemoteSigned执行后会有一个确认提示输入Y回车即可。如果不想要提示可以加-Force参数Set-ExecutionPolicy -Scope CurrentUser RemoteSigned -Force为什么选RemoteSigned而不是Unrestricted或者AllSigned关键在于RemoteSigned的规则是本地脚本可以不受限制地运行从互联网下载的脚本必须带数字签名。npm.ps1是安装Node时在本地生成的属于本地脚本所以能通过而从网上下载的恶意.ps1文件无法通过签名校验依然会被挡住。这个策略对开发者来说安全性和便利性平衡得最好。设置完之后重开一个PowerShell窗口再执行npm -v问题就解决了。我个人的习惯是把这条命令记在笔记里每换一台新电脑、每次重装开发环境到手第一件事就是把它跑一遍。3.3 方案三不碰PowerShell直接改用CMD运行npm这个方案最简单粗暴也不涉及任何策略改动。CMD不会校验PowerShell脚本所以你在CMD里执行npm时走的是npm.cmd完全绕开了签名检查。操作方式就是在任意终端窗口里先输入cmd回车切到命令行模式然后再执行npm命令。或者干脆修改VS Code的默认终端为Command Prompt打开VS Code设置搜索terminal.integrated.defaultProfile.windows把默认终端改成Command Prompt这样每次打开集成终端都是CMDnpm用起来完全没问题。不过我还是要说一句这个方案能解决一时之痛但PowerShell终端本身有很多不可替代的优势长期回避不是办法最好还是把执行策略设置好让PowerShell和npm能正常共存。3.4 为什么不推荐Unrestricted或者永久Bypass网上很多教程会教你Set-ExecutionPolicy Unrestricted。这条命令确实一次解决但我真的不建议在生产环境或日常开发机上这么干。Unrestricted意味着PowerShell对所有脚本完全放行不管这些脚本是来自本地还是从互联网下载的恶意文件。PowerShell本身是管理员工具很多恶意软件会伪装成.ps1脚本诱导你运行。一旦设成Unrestricted这些风险就全部敞开了。相比之下RemoteSigned只放行本地脚本对下载的远程脚本仍然保留签名校验这层防御是有实际意义的。哪怕你觉得自己只在自己电脑上开发身边没有恶意文件我也建议从良好习惯开始——哪天这台电脑要连公司内网、要跑一些第三方脚本你就知道当初没选Unrestricted是多么正确的决定。4. 网上流传命令失效的根源组策略、权限和策略优先级4.1 Get-ExecutionPolicy -List 的正确读法很多人执行了Set-ExecutionPolicy RemoteSigned之后发现还是不生效这时候别急着怀疑命令写错先用Get-ExecutionPolicy -List看一下全局情况。输出结果里会有5行左右每一行代表一个作用域。你排第一的是MachinePolicy排第二的是UserPolicy。如果这两个里面有具体的策略值比如Restricted而且不是Undefined那你就要小心了——这两项通常由组策略控制优先级高于CurrentUser和LocalMachine。也就是说即使你把CurrentUser设成了RemoteSigned只要MachinePolicy是Restricted系统依然会按Restricted处理。这种情况最常见于公司统一管理的电脑。IT部门通过组策略把PowerShell限制死了你本地怎么改都白搭。判断方法就是看Get-ExecutionPolicy -List的输出里MachinePolicy或UserPolicy是不是有确定的值。如果都显示Undefined那你改CurrentUser就一定有效。4.2 公司电脑被组策略锁死时的处理路径如果确认是组策略锁死了执行策略不要硬刚系统设置试试下面这几种路径在每个需要跑npm的PowerShell窗口里先用Set-ExecutionPolicy -Scope Process Bypass临时放行一次窗口关了自动恢复。用命令powershell -ExecutionPolicy Bypass -Command npm -v单次执行某条命令。干脆把VS Code默认终端改成Command Prompt让npm通过npm.cmd运行绕开PowerShell的规则。如果只是偶尔跑脚本也可以右键PowerShell窗口标题栏切到命令提示符模式直接在CMD里干活。这里要特别注意一点组策略锁定的情况下用管理员身份运行PowerShell也未必能改MachinePolicy。真有需求的话建议直接联系IT部门说明你是Node开发者需要安装开发环境申请放开本机PowerShell的RemoteSigned策略这才是正规路径。4.3 VS Code集成终端依然报错的问题定位还有一个高频场景系统PowerShell里设置好RemoteSigned了npm能正常运行但VS Code的终端里还是会报错。这个时候先别怪策略没生效大概率是终端会话的问题。VS Code集成终端在窗口打开时会启动一个新的PowerShell进程它继承的是系统当前的策略配置。如果你在外部PowerShell里改完策略VS Code是早就打开着的那它终端里的PowerShell进程还是旧策略状态重开VS Code或者重开集成终端就能解决。还有一种可能是VS Code终端配置里设置了额外的启动参数比如-ExecutionPolicy Restricted。检查一下设置里的terminal.integrated.env.windows和启动参数确保没有人为覆盖执行策略。这个点我踩过坑那次重装了Node都没解决最后发现是VS Code的shellArgs里多了一个-ExecutionPolicy RemoteSigned但写错了位置导致策略没生效。5. 改完策略之后的完整验证与日常使用建议5.1 验证执行策略和npm命令是否恢复设置完成之后重开PowerShell窗口按顺序执行以下命令Get-ExecutionPolicy -Scope CurrentUser node -v npm -v第一句的输出应该是RemoteSigned后面两句能正常打印版本号。这里我建议用新开的窗口验证不要直接在改完策略的那个窗口里测试——有些时候CurrentUser策略虽然改了但当前窗口的Process级别的旧策略还残留着会干扰你的判断。验证过程中如果发现npm -v能输出版本号但项目里执行npm install还是有问题那就要分开排查了可能不是npm本身的问题而是项目依赖装不上。别一见到npm报错就往PowerShell策略上想。5.2 实测安装一个小包确认端到端流程为了确认npm的整个调用链都畅通我喜欢新建一个临时目录装一个小包实测一下mkdir npm-test cd npm-test npm init -y npm install lodash如果npm install能正常执行看到进度条和输出说明PowerShell、npm、Node之间的链路完全打通了。这一步之后你再回头去看任何需要npm命令的前端项目都不会再遇到同样的签名报错。我在测试时还习惯顺带看下npm config get registry确认镜像源是不是正常的。有时候PowerShell策略解决了但registry指向了莫名其妙的地址导致安装卡住那是另一类问题和本篇的报错无关。5.3 以后装Node版本nvm / 手动解压时会遇到同样问题吗很多人在会用nvm-windows之后会顺手把Node从目录版迁移过去。这时候要留意nvm每次切换Node版本时会把对应版本的目录加进PATHnpm.ps1也被重新解析了一次。只要PowerShell的CurrentUser策略还是RemoteSigned新版本的npm.ps1同样是本地脚本不会触发签名拦截。真正容易踩坑的是升级Node版本或者切换nvm目录之后当前已经打开的PowerShell窗口还保留着旧命令路径。比如之前用的v22版本的npm.ps1切换到v24后旧窗口里敲npm -v可能指向的还是旧目录。解决办法很简单关掉终端重开或者执行refreshenv。如果你用的是nvm-windows切换版本后务必重开终端这是很多人的习惯也是减少诡异问题的最有效手段。5.4 最后一件事把执行策略的度控制在自己手里最后分享一个我个人的操作习惯。我不会把执行策略永远固定在一个值上而是分成两套日常开发机CurrentUser设为RemoteSigned既可以跑npm和各类全局工具又保留了远程脚本的签名校验。临时借用的电脑或者一次性环境用-Scope Process Bypass应急用完就关窗口不留下任何持久化的策略修改。这个习惯让我在解决这类问题时几乎不产生任何后遗症。你不需要照搬所有细节但记住一个原则就够了别为了一次方便把安全策略完全关掉用最小的权限改动解决眼前的问题才是长久之道。以后再遇到yarn.ps1、pnpm.ps1、某个全局工具生成的PowerShell脚本报同样的数字签名错误你也知道第一时间该做什么了。