先记住这个答案
spawnSync、execSync 和 execFileSync 会同步等待子进程完成，使调用它们的 Node 线程无法继续处理事件循环回调。它们适合有界、可预测且接受等待的一次性 CLI 或启动步骤；服务请求路径通常应使用异步子进程或独立任务执行器。spawnSync 通过结果对象表达退出状态和启动错误，execSync、execFileSync 则会在相应失败时抛错。timeout 通常触发终止信号，但若子进程处理信号后继续运行，同步调用仍可能等待，不能把它当作严格的墙钟期限。
- 阻塞的是调用线程的事件循环
- spawnSync 非零退出要检查结果对象
- timeout 发信号不等于保证立即返回
同步等待会影响同一事件循环上的其他任务
如果 HTTP 处理线程在路由里执行长时间同步子进程调用，它无法及时运行其他请求回调和定时器。即使外部程序自己在另一个进程里计算，调用方选择同步等待仍会影响该线程负责的并发工作。
一次性构建校验或短启动检查可能接受这种顺序等待，但前提是任务有明确边界。启动一个长期服务器再同步等待它退出，通常会让后续脚本步骤永远没有机会执行，不能只因为代码位于 CLI 就认定合适。
spawnSync 的失败结果不能照搬 execSync 处理
下面子程序输出诊断后以非零状态退出，spawnSync 仍返回结果对象。调用者需要检查 status 与 signal，并先处理 result.error；仅写 try/catch 而不检查状态，会漏掉程序运行后的非零退出。
execSync 和 execFileSync 对超时或非零退出等失败会抛出带有执行结果信息的错误。选择 API 后应按它的契约读取输出与状态，不能用同一段不区分返回方式的包装代码覆盖所有同步接口。
import { spawnSync } from 'node:child_process';
export function inspectSyncExit() {
const result = spawnSync(process.execPath, ['-e',
'process.stdout.write("diagnostic");process.exitCode=7'
], { encoding: 'utf8', timeout: 2000, maxBuffer: 4096 });
if (result.error) throw result.error;
return { status: result.status, signal: result.signal, stdout: result.stdout };
}这个受控任务应返回非零 status 和完整诊断文本，而不是因为非零退出自动进入 catch。真实脚本应据此决定是否中止后续步骤，不能只看函数已经返回就把任务视为成功。
timeout 与输出预算都不是无限任务的解药
同步方法达到 timeout 后会按选项发送终止信号，并继续等待进程实际结束。若程序截获默认 SIGTERM 并不退出，调用可能超过设定时长；同一线程中的普通定时器也无法在同步等待期间运行来替它兜底。
因此对可能失控的任务，应采用异步监督或独立执行边界，明确升级终止、进程树回收和配额释放。输出上限同样需要按字节和并发预算设计，大结果宜改用流或文件，不应无限增大缓冲来维持同步便利。
容易答错的地方
- 声称 timeout 到点就一定抛错返回
- 超时通常意味着发送终止信号，不代表子进程已经结束。同步 API 仍会等待实际结束，因此要核对目标程序的信号行为；需要严格期限的任务不能只依赖同一线程上的同步等待选项。
- 把所有同步方法都当成非零退出自动抛错
- spawnSync 需要检查结果对象，而 execSync 等接口有自己的抛错契约。应测试启动失败、非零退出和信号结束，保留原始状态信息，避免失败步骤被误判为成功后继续执行后续流程。
面试官还会怎么问？
把同步调用放进 worker_threads 就完全没成本吗？
它会阻塞该工作线程，而不是主线程的事件循环，但仍占用执行资源并需要管理超时、退出和并发。是否值得取决于任务隔离需求，不能通过换线程掩盖无限等待或无法回收的子进程。
execFileSync 相比 execSync 改善了什么？
它默认直接运行程序并用参数数组传参，减少 shell 解释带来的风险；但仍是同步等待，也仍要检查目标程序的危险选项、输出规模和运行权限。无 shell 不等于没有资源或参数安全问题。
一次性脚本用异步方式一定更复杂吗？
不一定，Promise 与 async/await 同样可以表达顺序执行，并保留取消和并发控制空间。同步方式的优势是小型脚本直观，选择应围绕等待是否可接受，而不是把异步写法一概描述成嵌套回调。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。