家庭资产配置底层逻辑：从五大类资产到再平衡，搭好财富架构
2026/10/6 9:48:31
1. 问题现象与根因分析
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。有些环境里路径可能是D:\nodejs\npm.ps1或者D:\Program Files\nodejs\npm.ps1，取决于你当初把Node.js装到哪个盘哪个目录。路径不同，但报错语义完全一样：PowerShell的脚本执行策略（Execution Policy）拦住了npm.ps1这个脚本。
很多人的第一反应是：我明明装好了Node.js，环境变量也配了，node -v能正常输出版本号，怎么偏偏npm -v就不行？这个困惑非常典型，因为node是exe可执行程序，直接运行不需要脚本引擎介入；而npm在Windows上是通过npm.ps1、npm.cmd、npm（shell脚本）这几个包装脚本去启动的。PowerShell执行外部命令时，会把npm解析成npm.ps1并尝试运行，于是执行策略就成了拦路虎。
1.2 为什么PowerShell要管这个事
说句公道话，PowerShell这个行为不算bug，它是故意的。脚本执行策略是Windows系统安全机制的一部分，目的是防止未签名的恶意脚本在你的机器上悄悄运行。默认的Restricted策略下，本机脚本和下载的脚本都不允许执行，这在某些企业环境和安全要求高的机器上是有意义的。
问题在于：Node.js官方安装包生成的npm.ps1脚本并没有做代码签名，它就是一个普通文本脚本。PowerShell不认识它，也懒得验证它，干脆一刀切：不让跑。所以你要做的不是抱怨这个机制蠢，而是理解它，然后用合理的方式放行。
这里有个非常关键的概念要分清：执行策略分为四个级别，分别是：
Restricted：默认策略，不允许任何脚本运行，但单条命令可以。RemoteSigned：本地创建的脚本可以运行，从网上下载的脚本必须经过数字签名。AllSigned：所有脚本必须签名才能运行。Unrestricted：所有脚本都可以运行，但下载的脚本运行前会提示。
常见的还有Bypass，表示完全不做任何拦截，什么都不提示。这个策略是分作用域的，你可以只对当前用户设置，也可以对整台机器设置，甚至可以只对当前PowerShell进程临时生效。
1.3 为什么node -v正常而npm -v报错
我见过很多人卡在这个问题上绕不出来，其实用一个简单的比喻就能想明白：node和npm的关系，有点像汽车的发动机和方向盘。发动机构造复杂，但它是独立运行的硬件；方向盘需要一套液压或电子助力系统去配合，这个系统出问题，方向盘就转不动。
具体到命令行世界：
node.exe是真正的可执行文件，双击也好、命令行调用也好，Windows直接加载它，跟脚本策略无关。npm本身是一个JavaScript文件（npm-cli.js），它依赖Node.js运行时去执行。为了让用户在命令行里直接敲npm就能调用，Node.js安装包在bin目录下生成了三个包装脚本：npm（Linux/macOS用）、npm.cmd（cmd用）、npm.ps1（PowerShell用）。
你在PowerShell里敲npm -v，PowerShell会按照PATHEXT和环境变量的顺序去查找命令，优先找到npm.ps1，然后尝试执行这个PowerShell脚本。这一步触发了执行策略的校验，于是被拦下。
而在cmd命令行窗口里敲npm -v，走的是npm.cmd，cmd没有脚本策略这一说，所以大部分情况下没问题。很多人装了Node.js后习惯用cmd验证，发现一切正常，换到PowerShell就翻车，原因就在这里。
2. 三种最常用的解决方案
2.1 方案一：修改当前用户的执行策略（推荐）
这个方案在社区里流传最广，操作也最简单。打开PowerShell，以管理员身份运行，然后执行：
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser执行完会提示你是否确认，输入Y回车即可。然后重新打开PowerShell，再执行npm -v，大概率就正常了。
这里解释一下为什么选RemoteSigned而不是Unrestricted或Bypass：
RemoteSigned允许本地脚本直接运行，从网上下载的脚本如果有数字签名也可以运行，没签名的不行。这个级别既兼顾了日常开发需求，又保留了基本的安全底线。Unrestricted太宽松，下载的脚本运行时会弹窗提示，虽然能跑但每次都要多点一下，烦得很。Bypass等于彻底关闭防御，适合单纯的临时测试环境，不适合作为长期设置。
用-Scope CurrentUser而不是默认的LocalMachine
这个细节很多人不注意。不加-Scope参数时，默认作用域是LocalMachine，会影响这台机器上的所有用户。如果你只是为了自己开发方便，没必要动全局配置，而且有些公司电脑的组策略会覆盖本地设置，你改了LocalMachine可能也被拉回去。所以：
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser这条命令只修改当前Windows用户的PowerShell执行策略，不会影响其他用户，也不会触发UAC管理员权限要求（实际上非管理员也可以执行，因为它只改当前用户）。考虑到公司电脑或共享机器的场景，这个方式最温和。
2.2 方案二：只对当前PowerShell会话临时放行
如果你只是急着跑一条命令，不想动系统策略设置，可以用-Scope Process。这个参数的意思是：只对当前这个PowerShell进程生效，窗口一关就还原。
Set-ExecutionPolicy RemoteSigned -Scope Process然后是老流程：
npm -v这个方案的好处是零残留、零风险，关掉窗口什么都不留下。坏处也显而易见：每次新开PowerShell窗口都要重新执行一次设置命令，非常不适合需要频繁开终端干活的人。我一般只建议在两种场景下用它：一是临时借别人的电脑跑个命令，二是想先验证一下npm确实能用、再决定要不要做永久修改。
2.3 方案三：直接在命令行里绕过PowerShell脚本
还有一种思路是根本不走npm.ps1，直接用npm.cmd。在PowerShell里执行：
npm.cmd -v加了.cmd后缀后，PowerShell会直接调用cmd脚本，绕开执行策略检查，npm -v的命令就能正常输出。这个方法几乎不怎么动配置，适合那些只想赶紧看到版本号、不想深入了解策略机制的读者。
但这个方法有个副作用：如果你习惯用npm run dev这类命令跑项目，每次都要敲npm.cmd run dev，手感和习惯上很不舒服。而且某些脚本内部会调用npm命令，这时候还是会撞上策略问题。所以我更倾向于把执行策略一次改好，而不是长期用npm.cmd绕路。
2.4 方案汇总对比
| 方案 | 命令 | 作用范围 | 是否持久 | 适用场景 |
|---|---|---|---|---|
| 当前用户策略修改 | Set-ExecutionPolicy RemoteSigned -Scope CurrentUser | 当前Windows用户 | 持久 | 推荐，日常开发标配 |
| 进程级临时放行 | Set-ExecutionPolicy RemoteSigned -Scope Process | 当前PowerShell窗口 | 临时，关窗失效 | 快速验证、临时用别人电脑 |
| 直接调用cmd包装脚本 | npm.cmd -v | 单条命令 | 不持久 | 应急查看版本、不想改配置 |
3. 实操验证与配套配置
3.1 改完整套流程的实测记录
我拿一台干净的Windows 10专业版机器做了完整测试，记录一下过程。新装Node.js 20.11.1 LTS版本后，打开PowerShell直接敲npm -v，果然复现了报错。然后按方案一执行：
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser系统询问是否要更改执行策略，输入Y。
紧接着继续输入：
npm -v这次输出正常，显示版本号10.2.4。再顺手验证一下：
node -v显示v20.11.1，两个命令都通了。为了确认没有破坏其他功能，我试着执行npm config get registry查看镜像源，输出的是默认的https://registry.npmjs.org/，一切正常。
再测试一个实际场景：临时创建一个项目目录，执行npm init -y，生成package.json文件也没问题。说明执行策略放行后，npm的初始化、安装、运行脚本等常用功能都能正常使用。
3.2 其他验证方法：Get-ExecutionPolicy -List
如果你想确认当前的执行策略到底是怎么设置的，可以在PowerShell里执行：
Get-ExecutionPolicy -List输出会显示各个作用域当前的策略值，比如：
Scope ExecutionPolicy ----- -------------- MachinePolicy Undefined UserPolicy Undefined Process Undefined CurrentUser RemoteSigned LocalMachine Undefined重点看CurrentUser这一行是不是RemoteSigned。如果显示Undefined，说明你没修改成功或者修改被还原了；如果是Restricted，说明还在默认限制状态，需要重新设置。
另外还有一个查看当前生效策略的命令：
Get-ExecutionPolicy它会直接输出当前会话实际采用的策略值。如果当前没有做过任何Process级别的覆盖，那输出的就是CurrentUser作用域的值。这套查证流程，建议每个遇到报错的读者都跑一遍，比盲猜问题定位快得多。
3.3 顺带把npm的国内镜像源也配好
既然都折腾到npm了，索性把镜像源也配了。国内直连npm官方源经常卡在网络延迟上，装个依赖等半天，尤其是一些大包，下载速度感人。建议设置成淘宝镜像源（现在叫npmmirror）：
npm config set registry https://registry.npmmirror.com设置完以后可以用npm config get registry验证，输出应该是https://registry.npmmirror.com。如果要恢复官方源，执行：
npm config set registry https://registry.npmjs.org/这里提个醒：不要为了追新去设置那些不知名的第三方镜像，稳定性完全没法保证。npmmirror是国内用得最多、更新频率也跟得上的镜像，基本能满足日常开发需要。另外，公司内网如果自建了npm私服，可以用npm config set registry http://内网地址指向私服，效果也是一样的。
3.4 关于Node.js版本的另一个坑
排查npm命令问题的时候，顺带看过一些报错信息里提到node.js v24.21.0 is not yet released or is not available。这个典型问题是版本号输入错误，或者用了尚未正式发布的版本号。npm安装包时如果用node@24.21.0这种不存在的版本号，就会触发这个错。
解决办法很简单：去Node.js官网的Release页面查一下当前最新版本，或者用：
npm view node version查看Node.js最新版本号，再决定要不要升级。日常开发不建议盲目追新版，LTS版本才是稳妥选择。比如Node.js 20.x、22.x这类的LTS版本，稳定性经过了大量生产环境验证，遇到问题社区资料也全。
4. 常见问题与排查技巧实录
4.1 为什么修改执行策略后依然报错
有一种情况比较隐蔽：你确实执行了Set-ExecutionPolicy RemoteSigned -Scope CurrentUser，但重新打开PowerShell后依然报了同样的错。这时候要排查两个方向：
第一，查看是不是有组策略在覆盖你的设置。执行Get-ExecutionPolicy -List，如果MachinePolicy或UserPolicy不是Undefined，说明是组策略强制指定的值，你的CurrentUser设置会被它压在下面。这种情况下，如果你有管理员权限，可以尝试通过本地组策略编辑器修改，路径是计算机配置 -> 管理模板 -> Windows组件 -> Windows PowerShell，找到“打开脚本执行”这一项，改成允许本地脚本和远程签名脚本。但如果是公司统一管控的电脑，建议直接联系IT，别自己硬刚。
第二，检查是不是因为远程下载的PowerShell脚本被标记了Zone.Identifier。有时候你手动下载的npm脚本或项目脚本会带上网下载标记，RemoteSigned要求这类脚本必须签名才能运行。这时候可以把文件右键打开属性，如果底部有“解除锁定”复选框，勾选后确认。
4.2 用管理员身份还是普通身份
很多人看到网上教程说要“以管理员身份运行PowerShell”，就以为普通用户什么都做不了。实际上-Scope CurrentUser的修改，普通用户权限就够了。真正需要管理员权限的是-Scope LocalMachine这种系统级修改。
但如果你发现普通用户权限下执行Set-ExecutionPolicy报错，提示“未授权”或“拒绝访问”，那可以右键PowerShell图标，选择“以管理员身份运行”，再执行一次即可。
4.3 PowerShell和cmd共存的问题
我遇到过不少用户，cmd里npm -v正常，PowerShell里报错，于是怀疑自己Node.js环境变量配置有问题，反复折腾Path变量。其实这两个终端走的是不同的启动路径，PowerShell优先找.ps1，cmd优先找.cmd。如果PowerShell报错但cmd正常，问题大概率在执行策略，跟环境变量没关系。
反过来说，如果你在cmd里也找不到npm，那才是真正的环境变量配置问题。需要检查PATH是否包含Node.js安装目录，比如C:\Program Files\nodejs\，或者检查安装时是不是勾掉了“Add to PATH”选项。
4.4 排查流程图简化版
这个问题虽然简单，但实际排查时最好按顺序走一遍，省得来回试：
- 先确认
node -v是否正常。如果node本身都报“不是内部或外部命令”，说明环境变量有问题，去检查PATH。 - 再确认
npm -v在cmd里是否正常。如果cmd里正常，PowerShell里报错，基本锁定执行策略问题。 - 执行
Get-ExecutionPolicy查看当前策略值。 - 执行
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser放行。 - 重新打开PowerShell窗口再测试。
4.5 报错信息里的“因为在此系统上禁止运行脚本”具体含义
这句话的英文原版是because running scripts is disabled on this system，翻译得比较直白。它的核心含义是：这个PowerShell脚本（npm.ps1）没有被当前执行策略允许运行。需要注意，这里说的“系统禁止”不代表Windows系统本身板死，而是PowerShell执行策略这个配置项在起作用。心理上不用慌，这跟病毒、安全入侵没关系，只是配置层面的“许可”问题。
4.6 关于Visual Studio Code里内置终端报错的补充
很多人在VS Code里打开终端执行npm -v，发现同样报错。这是因为VS Code默认的终端类型是PowerShell，走的还是PowerShell的执行策略。解决办法跟前面一模一样：在VS Code的终端里执行一次Set-ExecutionPolicy RemoteSigned -Scope CurrentUser，或者把终端类型改成cmd，在VS Code里按下Ctrl+Shift+P，输入Terminal: Select Default Profile，选择Command Prompt。这个技巧对只用VS Code开发前端项目的人来说很实用，因为大多数人不会专门去改VS Code的默认终端配置。
4.7 npm包管理器自身的其他常见报错
趁这个机会把几个高频npm报错一起说了，后台私信里这些问题的出现频率也很高。
报错1：npm WARN eresolve overriding peer dependency
这个通常是你安装的某个包和它声明的peerDependencies版本冲突导致的。npm 7以上版本对peer dependency的检查变得非常严格，不会自动忽略版本不匹配。解决办法是：优先考虑升级或降级相关包的版本，让版本匹配；实在想强行装，可以用--legacy-peer-deps参数绕过检查，但这不是长久之计，后面跑测试或构建时还可能踩坑。
报错2：missing optional dependency @openai/codex-win32-x64
这个看着吓人，其实是npm在安装某个包时，对应平台的可选依赖没被正确安装。常见原因是网络抖动，或者npm缓存出了问题。可以先执行：
npm cache clean --force再重新安装一次，如果还不行，把node_modules删除后重新跑npm install，大多数情况下能解决。
报错3：Error installing 24.21.0: node.js v24.21.0 is not yet released
前面提过，这是版本号不存在的典型报错。用npm view node version确认可用的版本列表，挑一个真实存在的版本号。
4.8 安全提示：不要为了省事直接开Bypass
有些“快捷教程”会让你执行：
Set-ExecutionPolicy Bypass -Scope CurrentUser甚至还有人建议改注册表HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell里的ExecutionPolicy值。这些方式确实能解决问题，但属于“用火箭炮打蚊子”。Bypass意味着PowerShell不校验任何脚本签名，临时跑通没问题，长期开着等于给恶意脚本开了一扇门。尤其是经常从网上下载开源项目的人，包里万一夹带一个.ps1恶意脚本，Bypass状态下它就能直接运行。
我个人坚持用RemoteSigned，它是安全和便利的折中。如果你实在不放心，可以在运行完npm相关命令后，再执行一次：
Set-ExecutionPolicy Restricted -Scope CurrentUser把策略收回去。虽然这样有点麻烦，但安全性和灵活性都兼顾了。
4.9 清理npm缓存和全局包的补充经验
有时候npm -v能跑通，但后续安装包时遇到各种奇怪问题，比如反复失败、下载到一半卡住、校验hash不匹配，大概率是npm缓存脏了。执行：
npm cache verify这是验证并清理损坏缓存的安全命令，比npm cache clean --force温和一些，建议先跑verify再跑clean。
另外，卸载全局包用：
npm uninstall -g <包名>如果你忘了自己装过什么全局包，用：
npm list -g --depth=0一次性倒出来看看，清爽很多。这套操作配合执行策略修复，算是一整套npm环境“体检”流程了。
5. 从踩坑到建议：我的实际体会
整个问题虽然门槛不高，但每个初学者基本都要踩一遍。我的建议是：解决完之后，顺手把执行策略、镜像源、全局依赖列表都过一遍，一次折腾到位，后面能省很多麻烦。
我个人在实际操作中的体会是：Windows的PowerShell脚本策略是安全机制，不是开发环境的敌人。理解它的逻辑之后，你就能明白什么时候该用RemoteSigned、什么时候该用Process、什么时候该用npm.cmd绕路，而不是一股脑把所有限制都关掉。这些命令看起来简单，背后的设计意图和适用场景才是真正值得消化的东西。
最后再分享一个小技巧：如果你经常在不同机器之间切换开发环境，可以把下面这几条命令保存成一个init.ps1脚本，每次新机器上装完Node.js后直接跑一遍：
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser npm config set registry https://registry.npmmirror.com npm install -g npm@latest node -v npm -v顺手把npm自身也升级到最新版本。这样每次环境初始化都能一步到位，不用再对着红色的报错信息发愁了。