VSCode终端npm run build失败大概率因第三方工具（如pnpm、vercel、nx）全局注入污染性NODE_OPTIONS环境变量；可通过echo命令确认，临时用unset或set清空，永久修复需在settings.json中配置对应系统空值覆盖并重启VSCode。
VSCode终端里npm run build突然失败，报错信息里出现奇怪的NODE_OPTIONS或NODE_ENV值，不是你设的——大概率是第三方工具（比如pnpm、vercel、nx）在全局注入了污染性环境变量，必须手动剥离。
如何确认NODE_OPTIONS被第三方工具污染
VSCode终端执行echo $NODE_OPTIONS（macOS/Linux）或echo %NODE_OPTIONS%（Windows），如果输出类似--no-warnings --max-old-space-size=8192或--enable-source-maps，且你没主动设置过，基本就是被pnpm、vercel CLI或某些monorepo工具写入了全局环境变量。
- pnpm会在首次运行时自动写入
NODE_OPTIONS到用户配置（如~/.pnpm-global/config或Windows注册表） - vercel CLI安装后可能通过
vercel env命令持久化环境变量，影响所有后续Node进程 - nx workspace默认启用
NODE_OPTIONS=--max-old-space-size=4096，且会写进nx.json或.nx/env，VSCode终端启动时继承该值
为什么污染会导致打包失败
Webpack、Vite、ESBuild等构建工具对NODE_OPTIONS极其敏感：它会被Node.js进程无条件加载，覆盖脚本自身传入的参数。常见后果包括：
-
--no-warnings导致TypeScript编译错误不报出，静默失败 -
--enable-source-maps强制开启source map生成，但未配devtool字段时引发Webpack内部冲突 -
--max-old-space-size=8192在CI或低内存机器上反而触发OOM（Node堆上限过高，GC策略失效） - 多个工具叠加注入（如pnpm + vercel），
NODE_OPTIONS变成超长字符串，Node解析时报Invalid argument
临时清除污染的最快方法
在VSCode终端当前会话中立即生效，不改系统配置：
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- macOS/Linux：
unset NODE_OPTIONS && npm run build - Windows PowerShell：
$env:NODE_OPTIONS=""; npm run build - Windows CMD：
set NODE_OPTIONS=&& npm run build
注意：unset或set NODE_OPTIONS=只作用于当前shell进程，关掉终端就失效，适合快速验证是否为环境变量问题。
永久修复：隔离VSCode终端的NODE_OPTIONS
别指望第三方工具“别乱写”，直接在VSCode层面切断继承链。编辑settings.json，根据系统加对应配置：
- macOS：
"terminal.integrated.env.osx": { "NODE_OPTIONS": "" } - Windows：
"terminal.integrated.env.windows": { "NODE_OPTIONS": "" } - Linux：
"terminal.integrated.env.linux": { "NODE_OPTIONS": "" }
关键点：空字符串""会覆盖父进程传入的任何值，比unset更彻底；必须重启VSCode才能生效——只重载终端不行，因为环境变量在进程启动时固化。
真正麻烦的不是怎么清，而是哪些地方偷偷写了又不告诉你。比如pnpm setup执行后，它根本不会提示“已修改你的全局NODE_OPTIONS”，而VSCode终端照单全收。所以每次装新CLI工具后，都值得跑一次echo $NODE_OPTIONS看看有没有陌生内容。
