现在这条报错里，最醒目的其实不是 `env-cmd`，也不是 `nx serve`，而是这一行

```text
npm error syscall spawn C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe
```

紧接着又出现

```text
npm error enoent spawn C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe ENOENT
```

从这两行基本可以把问题范围压缩得很小。

当前的 `npm` 正在尝试启动

```text
C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe
```

但 Windows 已经找不到这个文件，所以创建子进程失败。

这里的关键点在于，问题发生在 `npm` 准备执行 `package.json` 中的 `start` 命令之前。也就是说，目前没有充分理由怀疑 React、Angular、Nx、`env-cmd`，甚至没有理由先去删除 `node_modules`。真正需要检查的是

```text
npm 为什么会认为 bash.exe 位于这个旧目录
```

而从路径中的

```text
Git20180223
```

来看，这极像以前安装过的一套旧版 Git for Windows，后来 Git 被升级、迁移或者删除了，但 `npm` 仍然保存着旧的 Bash 路径。

官方 `npm` 文档说明，Windows 上运行 `npm run` 时，默认脚本 Shell 是 `cmd.exe`，但可以通过 `script-shell` 配置修改成其他 Shell。[docs.npmjs.com](https://docs.npmjs.com/cli/start.html/?utm_source=chatgpt.com)

Node.js 官方文档也明确说明，当 `spawn` 要执行的命令不存在时，会直接产生 `ENOENT`。所以这里的 `ENOENT` 并不是 npm registry 找不到包，也不是 `package.json` 找不到，更不是 `node_modules` 缺文件，而是待创建的进程本身不存在。[Node.js](https://nodejs.org/download/release/v26.8.2/docs/api/child_process.html?utm_source=chatgpt.com)

## 先把当前问题拆开看

当前 `package.json` 中的脚本大概类似

```text
env-cmd --no-override -e dev,b2c,$SPA_ENV -- nx serve storefrontapp --configuration=development
```

执行

```cmd
npm run start
```

正常的调用链应该近似理解成

```text
npm
 ↓
脚本 Shell
 ↓
env-cmd
 ↓
nx
 ↓
Angular / React
```

而现在真正发生的是

```text
npm
 ↓
尝试启动 C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe
 ↓
文件不存在
 ↓
ENOENT
 ↓
整个流程停止
```

因此 `env-cmd` 实际上还没有正常进入工作状态，`nx serve` 更没有机会启动。

这一点非常重要，因为如果一看到 `npm run start` 失败就执行

```cmd
rmdir /s /q node_modules
npm cache clean --force
npm install
```

大概率是在处理错误的层次。

即使重新安装几十万甚至上百万个 `node_modules` 文件，`npm` 下一次执行脚本时仍然会去寻找同一条已经失效的

```text
C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe
```

结果还是 `ENOENT`。

我们真正需要找到的，是这个旧 Bash 路径究竟从哪里来的。

## 最值得马上执行的几个命令

在当前项目目录

```text
C:\Oracle\code\spa\React
```

打开 `cmd`，直接执行

```cmd
npm config get script-shell
```

这条命令非常关键。

我判断这里很可能直接得到类似结果

```text
C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe
```

如果真的得到这个结果，基本就已经定位完成。

因为 `script-shell` 正是 `npm run` 用于决定脚本解释器的配置项。

官方文档给出的 Windows 默认值是 `cmd.exe`，而不是 Git Bash。只有配置被人为改过，`npm` 才会使用其他 Shell。[npm Docs](https://docs.npmjs.com/cli/using-npm/config/?utm_source=chatgpt.com)

继续执行

```cmd
npm config list
```

以及

```cmd
npm config ls -l
```

这里的目的不是查看 npm package，而是把 npm 当前生效的配置展开。

还可以执行

```cmd
npm config get userconfig
```

通常会看到类似

```text
C:\Users\I042416\.npmrc
```

再执行

```cmd
npm config get globalconfig
```

这样可以找到全局 npm 配置文件。

`npm` 官方文档说明，它可能从项目 `.npmrc`、用户 `.npmrc`、全局 `.npmrc`、环境变量和命令行参数等多个来源读取配置，而且配置存在优先级。当前官方文档给出的主要优先级关系包括命令行、环境变量、项目配置、用户配置、全局配置。[npm Docs](https://docs.npmjs.com/files/npmrc/?utm_source=chatgpt.com)

因此还可以直接检查当前项目

```cmd
type .npmrc
```

如果文件存在，关注有没有类似内容

```text
script-shell=C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe
```

再检查用户级配置

```cmd
type %USERPROFILE%\.npmrc
```

这里尤其值得检查。

很多 Windows 开发环境里曾经执行过类似 npm 配置命令，把 Git Bash 固定成 `npm run` 的 Shell。几年后重新安装 Git，原来的 Git 目录消失，但 `%USERPROFILE%\.npmrc` 一直保留下来，于是所有项目继续继承这条过期路径。

还不能忽略环境变量。

执行

```cmd
set npm_config
```

观察有没有类似

```text
npm_config_script_shell=C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe
```

npm 官方文档明确说明，`npm_config_` 开头的环境变量会被作为 npm 配置读取，所以即使 `.npmrc` 已经修改正确，如果 Windows 环境变量中还有旧的 `npm_config_script_shell`，旧路径依然可能继续生效。[npm Docs](https://docs.npmjs.com/cli/v11/using-npm/config/?utm_source=chatgpt.com)

这一点经常造成一种很迷惑的现象。

明明打开

```text
C:\Users\I042416\.npmrc
```

已经没有 `script-shell` 了，执行 `npm run start` 却依旧寻找旧 Bash。

原因往往就在环境变量这一层。

## 这个项目有一个细节，不能简单地把 Bash 删除掉

如果只是普通 Angular 项目，我通常会倾向于恢复 Windows 默认的 `cmd.exe`。

但当前 React 项目的命令中出现了

```text
$SPA_ENV
```

完整片段是

```text
-e dev,b2c,$SPA_ENV
```

这个细节非常重要。

`$SPA_ENV` 属于典型的 Unix Shell / Bash 风格变量引用。

Windows `cmd.exe` 使用的环境变量语法是

```cmd
%SPA_ENV%
```

PowerShell 则通常写成

```powershell
$env:SPA_ENV
```

Bash 才是

```bash
$SPA_ENV
```

所以从当前 `start` 脚本的写法来看，这个工程很可能原本就是有意识地要求 `npm run` 经由 Bash 执行，而不是偶然配置了 Git Bash。

因此现在有两条不同的修复路线。

不能看到 `script-shell` 就机械地删除，而要结合项目本身的脚本设计判断。

`env-cmd` 官方文档也提供了环境变量展开功能，并明确提到了 `$VAR` 形式参数的展开。同时，`-e` 用于从 `.env-cmdrc` 中选择一个或多个 environment。当前命令里的 `dev,b2c,$SPA_ENV` 很像项目希望 Bash 先解析 `SPA_ENV`，再把最终 environment 名称传给 `env-cmd`。[npm](https://www.npmjs.com/package/env-cmd?activeTab=versions\&utm_source=chatgpt.com)

例如，如果当前

```text
SPA_ENV=local
```

那么 Bash 看到

```text
-e dev,b2c,$SPA_ENV
```

会把它变成近似

```text
-e dev,b2c,local
```

`env-cmd` 随后从 `.env-cmdrc` 中合并

```text
dev
b2c
local
```

三个 environment。

因此对于这个项目，我更倾向于认为

```text
原来的 Git Bash 路径失效
```

比

```text
项目根本不应该使用 Bash
```

更符合现场情况。

## 我建议按照下面这个顺序修复

1. 先确认旧 Bash 确实不存在

执行

```cmd
dir C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe
```

如果得到找不到文件，就与 `ENOENT` 完全吻合。

还可以运行

```cmd
where git
```

以及

```cmd
where bash
```

现在的 Git 很可能已经位于类似

```text
C:\Program Files\Git\cmd\git.exe
```

而 Bash 可能位于

```text
C:\Program Files\Git\bin\bash.exe
```

Git for Windows 官方资料说明，现代 Git for Windows 安装中确实存在 `<Git>\bin\bash.exe`，典型 `<Git>` 目录就是 `C:\Program Files\Git`。这个 `bash.exe` 还会进一步启动 Git for Windows 自带的实际 Bash 环境。[gitforwindows.org](https://gitforwindows.org/git-wrapper.html?utm_source=chatgpt.com)

所以可以检查

```cmd
dir C:\Program Files\Git\bin\bash.exe
```

如果这个文件存在，而旧目录不存在，那么问题已经非常明确。

当前 npm 配置指向的是

```text
C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe
```

而实际 Git Bash 已经移动到了

```text
C:\Program Files\Git\bin\bash.exe
```

2. 确定旧路径来自哪一层

执行

```cmd
npm config get script-shell
npm config list
npm config get userconfig
npm config get globalconfig
set npm_config
```

再检查

```cmd
type .npmrc
type %USERPROFILE%\.npmrc
```

只要在其中找到

```text
script-shell=C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe
```

就找到了根。

3. 如果这个 React 工程仍然需要 Bash，修改成当前 Bash 的真实位置

假设新的 Git 安装目录为

```text
C:\Program Files\Git
```

对应 Bash 就是

```text
C:\Program Files\Git\bin\bash.exe
```

可以直接修改 `.npmrc` 中的配置为

```text
script-shell=C:/Program Files/Git/bin/bash.exe
```

这里使用 `/` 可以避免 Windows 路径中大量反斜杠带来的可读性问题，Node.js 在 Windows 下一般能够正常识别这种路径表示。

修改之后执行

```cmd
npm config get script-shell
```

确认输出不再包含

```text
Git20180223
```

再执行

```cmd
npm run start
```

如果此时进入

```text
env-cmd
```

或者

```text
nx serve
```

阶段，即使出现新的错误，也说明当前这个 `ENOENT` 已经解决。

新的错误需要按新的层次分析，而不能再把它和 Bash 路径问题混在一起。

4. 如果项目实际上不要求 Bash，可以恢复 npm 默认 Shell

这种情况下可以执行

```cmd
npm config delete script-shell
```

再检查

```cmd
npm config get script-shell
```

重点不是它必须显示某一个固定字符串，而是不能继续显示那条旧的

```text
C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe
```

Windows 上 `npm run` 的默认 Shell 会回到 `cmd.exe`。[npm Docs](https://docs.npmjs.com/cli/v10/commands/npm-run-script/?utm_source=chatgpt.com)

不过当前工程存在

```text
$SPA_ENV
```

所以我不建议一上来就采用这条路线。

恢复 `cmd.exe` 后，原来的

```text
$SPA_ENV
```

不会按照 Bash 环境变量语法展开。

假设

```cmd
set SPA_ENV=local
```

在 Bash 中

```text
$SPA_ENV
```

可以得到

```text
local
```

但在 Windows `cmd.exe` 中真正对应的是

```cmd
%SPA_ENV%
```

因此很可能会把眼前的 Bash 错误修掉，却紧接着碰到 `env-cmd` environment 找不到之类的新问题。

对于当前项目，保留 Bash 并把 Bash 路径修正到当前 Git 安装位置，更像是低风险处理方式。

## `env-cmd` 和 `nx` 为什么现在不应该被怀疑

从日志顺序也可以得到非常有价值的信息。

当前输出是

```text
> storefrontapp@2607.0.0 start
> env-cmd --no-override -e dev,b2c,$SPA_ENV -- nx serve storefrontapp --configuration=development

npm error code ENOENT
npm error syscall spawn C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe
```

有时看到第二行打印出了 `env-cmd`，会产生一种感觉，似乎 `env-cmd` 已经启动并在内部失败。

实际上 `npm` 在运行 lifecycle script 时，会先把脚本文本打印出来，再调用指定 Shell 去解释它。

所以

```text
> env-cmd ...
```

被打印出来，并不代表 `env-cmd.exe` 已经成功执行。

当前 Shell 自己都没有成功创建。

可以把它类比成 Windows 准备执行一个 `.bat` 文件。

命令窗口已经显示

```text
即将执行某某脚本
```

但真正负责解释这个脚本的 `cmd.exe` 路径却不存在，那么脚本正文一行都执行不了。

现在只是把 `cmd.exe` 换成了配置中的

```text
bash.exe
```

Node.js 的 `child_process.spawn` 在找不到待执行命令时会产生 `ENOENT`，与当前日志完全一致。[Node.js](https://nodejs.org/download/release/v26.8.2/docs/api/child_process.html?utm_source=chatgpt.com)

因此目前没有必要做下面这些动作

```text
重新安装 Nx
升级 Angular
重新安装 React
删除 package-lock.json
清空整个 npm cache
重新拉 Git repository
修改 storefrontapp 的 Nx configuration
检查 OCC
检查 Commerce Cloud
```

这些全都比当前失败点更靠后。

调用链还没有走到那里。

## 一个很符合当前现场的真实演变过程

结合路径

```text
C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe
```

我认为很可能经历过类似这样的环境变化。

2018 年左右，本机或者这套开发环境安装了一份 Git，目录是

```text
C:\Oracle\app\Git20180223\Git20180223
```

为了让 npm script 支持 Bash 语法，曾经配置过

```text
script-shell=...\bin\bash.exe
```

后来 Git 被升级了。

新版 Git 很可能装到了

```text
C:\Program Files\Git
```

`git.exe` 本身之所以平时仍然可以工作，是因为 Windows `PATH` 已经指向新版 Git。

例如

```cmd
git --version
```

完全可能正常。

但 npm 的 `script-shell` 使用的并不是

```text
PATH 中搜索 bash
```

而是配置里保存的那个绝对路径。

于是出现一个非常容易误判的现象

```text
git 正常
node 正常
npm 正常
npm install 正常
npm run start 却报 bash.exe ENOENT
```

这并不矛盾。

因为前几个命令并不依赖那个旧 `script-shell`，只有执行 npm lifecycle script 时才真正触发。

这也是为什么这个问题可能突然出现。

项目源代码可能一行都没有改，某一天 Git 被升级或者旧开发工具目录被清理，`npm run start` 就开始失败了。

## 还可以做一次最直接的验证

假设当前新的 Bash 位于

```text
C:\Program Files\Git\bin\bash.exe
```

检查它

```cmd
dir C:\Program Files\Git\bin\bash.exe
```

再检查旧文件

```cmd
dir C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe
```

如果结果是一新一旧

```text
新路径存在
旧路径不存在
```

那么整个错误就已经闭环。

再把 npm 配置中的

```text
C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe
```

更新为新的 Bash 路径即可。

如果 `where bash` 什么都找不到，但 Git 已经安装，也可以检查 Git 的真实目录。

```cmd
where git
```

例如得到

```text
C:\Program Files\Git\cmd\git.exe
```

根据 Git for Windows 的标准目录结构，相应 Bash 通常就在

```text
C:\Program Files\Git\bin\bash.exe
```

Git for Windows 官方文档也列出了 `<Git>\git-bash.exe`、`<Git>\cmd\git.exe` 和 `<Git>\bin\bash.exe` 这些入口。[gitforwindows.org](https://gitforwindows.org/git-wrapper.html?utm_source=chatgpt.com)

## 关于 `$SPA_ENV` 还需要再检查一层

当 Bash 路径修好后，如果后面出现类似

```text
Failed to find environments
```

或者某个 environment 不存在，就应该检查

```cmd
set SPA_ENV
```

看看当前有没有定义

```text
SPA_ENV
```

因为 start script 包含

```text
dev,b2c,$SPA_ENV
```

假设什么都没设置，Bash 展开以后可能成为类似

```text
dev,b2c,
```

如果项目需要例如

```text
SPA_ENV=local
```

或者

```text
SPA_ENV=devlocal
```

那还需要按照项目约定设置正确的值。

`env-cmd` 的 `-e` 参数就是选择 `.env-cmdrc` 中的 environment，并且可以一次组合多个 environment。多个 environment 被加载时，后面的环境配置可以覆盖前面的同名变量。[npm](https://www.npmjs.com/package/env-cmd?activeTab=versions\&utm_source=chatgpt.com)

因此

```text
-e dev,b2c,$SPA_ENV
```

很可能是项目故意设计出来的分层方式。

例如

```text
dev
```

提供开发环境公共变量，

```text
b2c
```

提供 B2C Storefront 的公共变量，

```text
$SPA_ENV
```

再提供某个开发人员、本地 OCC、测试环境或者具体 deployment 的覆盖变量。

这也进一步加强了项目依赖 Bash 语法的可能性。

## 当前最推荐直接执行的一组命令

在当前的 `cmd` 中按照下面顺序跑即可

```cmd
cd /d C:\Oracle\code\spa\React

npm config get script-shell

npm config get userconfig

npm config get globalconfig

npm config list

set npm_config

where git

where bash

dir C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe

dir C:\Program Files\Git\bin\bash.exe

set SPA_ENV
```

这里最关键的是第一个。

如果

```cmd
npm config get script-shell
```

真的打印

```text
C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe
```

那么可以把当前问题判断为高确定性的

```text
npm script-shell 保存了已经失效的 Git Bash 绝对路径
```

对于这个 React 项目，由于 start script 中明确使用了

```text
$SPA_ENV
```

我更推荐把 `script-shell` 更新为当前真实的 Git Bash，而不是直接删除 Bash 配置。

期望的最终调用链应该恢复成

```text
npm run start
        ↓
当前有效的 Git Bash
        ↓
展开 $SPA_ENV
        ↓
env-cmd
        ↓
加载 dev、b2c 和 SPA_ENV 对应环境
        ↓
nx serve storefrontapp
        ↓
Angular / React dev server
```

而当前停在的是最上面的 Shell 创建阶段。

所以这次问题的核心可以压缩成一句话

`npm run start` 本身没有坏，React 也还没有真正启动，`npm` 被配置成使用一条 2018 年遗留下来的 Git Bash 绝对路径，而那个 `bash.exe` 现在已经不存在。

## 参考资料

npm 官方关于 `npm start`、`npm run` 与 `script-shell` 的说明。[npm Docs](https://docs.npmjs.com/cli/start.html/?utm_source=chatgpt.com)

npm 官方关于 `.npmrc`、项目配置、用户配置、全局配置及配置优先级的说明。[npm Docs](https://docs.npmjs.com/files/npmrc/?utm_source=chatgpt.com)

Node.js 官方关于 `child_process.spawn` 在命令不存在时产生 `ENOENT` 的说明。[Node.js](https://nodejs.org/download/release/v26.8.2/docs/api/child_process.html?utm_source=chatgpt.com)

Git for Windows 官方关于 `Git\bin\bash.exe`、`git-bash.exe` 与 Git Windows 目录结构的说明。[gitforwindows.org](https://gitforwindows.org/git-wrapper.html?utm_source=chatgpt.com)

`env-cmd` 官方说明，其中包含 `-e` 多 environment、`--no-override`、`$VAR` 参数展开及 Shell 执行相关机制。[npm](https://www.npmjs.com/package/env-cmd?activeTab=versions\&utm_source=chatgpt.com)

现在这条报错里，最醒目的其实不是 env-cmd，也不是 nx serve，而是这一行

npm run start 报 spawn ...\bash.exe ENOENT 的真正原因与完整修复思路

紫薇堂堂主

开发工具

前端

运维

npm run start报ENOENT错误，根源是npm配置的script-shell指向了失效的旧版Git Bash路径（C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe），导致npm无法启动脚本解释器。建议先执行npm config get script-shell定位旧路径，再将其更新为当前Git安装目录（如C:\Program Files\Git\bin\bash.exe）或删除配置恢复默认cmd.exe。注意项目start脚本使用了$SPA_ENV变量，需保留Bash环境。

代码解释

解释器

Windows

ReAct 

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

npm run start报ENOENT错误，根源是npm配置的script-shell指向了失效的旧版Git Bash路径（C:\Oracle\app\Git20180223\Git20180223\bin\bash.exe），导致npm无法启动脚本解释器。建议先执行npm config get script-she...

npm run start 报 spawn ...\bash.exe ENOENT 的真正原因与完整修复思路-腾讯云开发者社区-腾讯云

npm run start 报 spawn ...\bash.exe ENOENT 的真正原因与完整修复思路

npm run start 报 spawn ...\bash.exe ENOENT 的真正原因与完整修复思路

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐