Windows新旧笔记本npm脚本设置NODE_ENV差异原因排查

问题本质 #

NODE_ENV=production gulp build是类Unix Shell（比如Git Bash）的环境变量赋值语法，Windows原生的CMD/PowerShell不支持这种写法。旧Win10设备能正常运行，是因为npm脚本实际在Git Bash环境执行；新Win11设备报错，是因为npm用了不兼容该语法的原生Windows Shell（CMD/PowerShell）来执行脚本。

可能的差异原因 #

• npm默认Shell配置不同：旧Win10的npm被配置为使用Git Bash作为脚本执行Shell，新Win11的npm默认使用CMD或PowerShell。
• Git Bash集成优先级差异：旧设备的Git Bash路径在系统PATH中的优先级高于CMD/PowerShell，npm启动时优先调用Git Bash；新设备的Git Bash未被npm识别为默认Shell。
• WSL上下文关联差异：虽然都启用WSL，旧设备的npm脚本可能实际在WSL的Linux环境中执行（天然支持类Unix语法），新设备的脚本仍在Windows原生环境运行。
• nvm的执行环境差异：两台设备的nvm可能关联了不同的Shell环境，旧设备的nvm在Git Bash中初始化，新设备的nvm在CMD/PowerShell中初始化，导致npm继承了不同的Shell上下文。

具体排查方向 #

• 检查npm的Shell配置：在两台设备的Git Bash中执行npm config get shell，对比输出。旧设备应该返回Git Bash的路径（如C:\Program Files\Git\bin\bash.exe），新设备可能返回cmd.exe或powershell.exe。
• 验证Git Bash的PATH优先级：在新设备的CMD中执行where bash，看Git Bash的路径是否在结果中，且排在最前面。如果没有或优先级低，调整系统PATH顺序。
• 确认脚本实际执行的Shell：修改npm脚本为echo $SHELL && NODE_ENV=production gulp build，在新设备运行，看输出是否为Git Bash的标识。如果输出是CMD/PowerShell相关内容，说明Shell不对。
• 检查WSL的关联状态：在旧设备执行which node，看是否指向WSL内的node路径；新设备同样执行该命令，对比路径差异，确认是否WSL的上下文未被正确关联。
• 核对nvm的初始化配置：查看两台设备的Shell启动文件（Git Bash的.bashrc/.bash_profile，CMD的环境变量），确认nvm的初始化脚本是否在Git Bash中被正确加载，新设备是否遗漏了这一步。

内容的提问来源于stack exchange，提问作者noahmason