先记住这个答案
spawn 返回 ChildProcess 后，找不到可执行文件或指定 cwd 不存在等启动失败通常通过 error 事件报告，外层包住那次函数调用的同步 try/catch 接不到之后发出的事件。参数类型等调用前校验仍可能同步抛错，所以不能说 spawn 永远不抛异常。程序已经启动但以非零状态退出，则主要通过退出信息表达，也不等于产生 error 事件。应及时监听 error，并将启动失败和结束状态收敛到不会重复结算的任务接口。
- 异步 error 不会进入已经结束的同步 try/catch
- 非法参数仍可能同步抛错
- 非零退出与启动失败需要分别判断
try/catch 的作用范围止于当前调用栈
在 try 块里拿到 child 之后，JavaScript 可以继续执行，稍后启动失败通过事件系统通知。那时原来的 try 块已经结束，只有及时注册的 error 监听器能在相应路径处理错误。
EventEmitter 的 error 事件如果没有监听器，可能成为未处理错误使进程退出。应在创建对象后立即注册处理，而不是等待某个 data 或 exit 事件出现后才补监听；启动失败可能根本没有正常运行阶段。
把事件接口包装成单次结算的 Promise
下面保留原始错误对象，让调用方可以检查 code。Promise executor 内同步抛出的调用错误也会使 Promise 拒绝，异步 error 则显式拒绝；随后即使 close 到达，Promise 也不会再次改变结果。
示例只返回结束信息，非零退出是否视为业务失败由调用方明确判断。实际任务系统还应增加超时与并发控制；这里忽略输出是有意选择，不能把同样写法直接用于必须读取子进程结果的场景。
import { spawn } from 'node:child_process';
export function runCommand(file: string, args: string[] = []) {
return new Promise<{ code: number | null; signal: NodeJS.Signals | null }>((resolve, reject) => {
const child = spawn(file, args, { stdio: 'ignore' });
child.once('error', reject);
child.once('close', (code, signal) => resolve({ code, signal }));
});
}测试应分别传入不存在的绝对命令路径、正常退出的 Node 程序和非零退出的 Node 程序。前者拒绝 Promise，后两者返回不同退出码，证明启动错误与程序执行结果没有混为一谈。
排查 ENOENT 时同时检查目录与执行文件
日志里出现 ENOENT 后，先确认指定 cwd 存在，再确认执行文件路径或 PATH 查找结果。脚本依赖的解释器不可用也可能使启动链路失败，因此不能只查看脚本文件本身是否在磁盘上。
如果用了 exec 或 shell 模式，shell 自身可能成功启动，再把找不到命令作为非零退出报告。这与默认 spawn 无法启动目标程序的事件路径不同，排查前需要明确是否隔着一层 shell。
容易答错的地方
- 只监听 exit 就等待所有失败结束
- 启动失败时不应依赖一定收到 exit。需要监听 error 处理失败，并用合适的结束事件收尾；如果多个事件都可能触发同一业务回调，还要防止重复通知或重复释放资源。
- 把 exit code 非零转成 ENOENT
- 非零退出可能是参数无效、业务校验失败或程序内部错误，并不能推断文件不存在。应保留退出码、信号和经过限量处理的诊断输出，让上层根据具体程序协议分类处理。
面试官还会怎么问？
用 await spawn 能等待子进程完成吗？
不能。spawn 返回的是 ChildProcess 对象，直接 await 它不会自动等待 close 或退出。需要明确包装事件或使用相应 Promise 工具，同时处理 error，不能把异步创建接口误认为 Promise 接口。
Promise 包装就不需要处理重复事件了吗？
Promise 自身只结算一次，但事件监听器里的其他副作用仍可能重复执行。若有更新任务状态、释放配额或发送通知，应把这些动作放在统一收尾路径，不能只依赖 resolve 被忽略来避免重复副作用。
怎样在日志里保留足够信息又不暴露环境？
记录错误 code、受控的程序标识、目录校验结果和任务编号，必要时记录脱敏后的路径。不要输出全部环境变量或包含用户敏感参数的完整命令字符串，诊断信息应围绕可复现条件选择。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。