symfony process 的 start() 不等于真异步，因 php 请求结束会导致子进程被终止或孤儿化；真正可用方案是：① supervisord + messenger + redis；② nohup + exec()（仅 cli）；③ detach() + disableoutput()（仅调试）。
不能直接用 Symfony Process 的 run() 或 start() 实现“真异步”——它本身不处理进程生命周期跨请求，必须配合系统级守护或消息队列。
为什么 start() 不等于“后台运行完就不管了”
Symfony Process 的 start() 确实会 fork 子进程并立即返回，但它的默认行为是：父进程（PHP）仍持有子进程的 stdout/stderr 句柄，并在后续调用 wait() 或 isRunning() 时进行轮询。一旦 PHP 请求结束（比如 HTTP 响应发完），PHP 进程退出，子进程大概率被系统 SIGPIPE 或孤儿化后由 init 收养——这时你既收不到输出，也无法可靠判断是否成功。
-
start()后不调用wait()就返回响应，脚本可能被中断或静默失败 - Web 服务器（如 Apache、PHP-FPM）通常会 kill 掉所有子进程，尤其当超时或 worker 重启时
- 没有持久化状态，无法重试、查进度、通知完成
真正可用的三种落地方式（按推荐顺序）
必须让备份脚本脱离当前 HTTP 请求生命周期。选哪种取决于你的部署环境和运维能力：
-
推荐：用
supervisord+ Redis 队列（symfony/messenger） 把备份任务封装成 Messenger 消息，投递到 Redis，由 supervisor 管理的 worker 进程消费执行。Process 组件只用于 worker 内部调用 shell 脚本，此时 PHP 进程长期存活，wait()安全可靠。 -
轻量替代：用
nohup+exec()脱离终端 仅限 CLI 场景（如 cron 或手动触发）。示例：exec('nohup /path/to/backup.sh > /var/log/backup.log 2>&1 & echo $! > /tmp/backup.pid');。注意：需自行管理 pid 文件、日志轮转、错误捕获，Process 组件此时基本不用。 -
临时方案（不推荐生产）：用
detach()+disableOutput()$process = new Process(['./backup.sh']); $process->disableOutput()->setTimeout(null)->start();。这会让 Process 不绑定 stdout/stderr，但依然依赖 PHP 进程存活 —— 在 FPM 下极易失效，仅适合调试或本地开发验证流程。
Process 调用备份脚本时的关键参数陷阱
即使走 Messenger worker 路线，Process 的配置也直接影响备份稳定性：
- 务必设
setTimeout(null)，否则默认 60 秒超时会 kill 正在压缩大数据库的脚本 - 用
setWorkingDirectory()显式指定脚本路径，避免因 worker 启动目录不同导致cd失败或相对路径错乱 - 不要依赖
$_ENV或 shell profile（如~/.bashrc），FPM 或 supervisor 启动的 PHP 进程通常没有完整登录 shell 环境；用setEnv()显式传入PATH、HOME等必要变量 - 捕获退出码比输出更可靠：
if ($process->getExitCode() !== 0) { /* 记录失败，别只看 output */ }
备份脚本自身必须支持幂等与信号处理
Process 只是执行器，脚本才是关键。很多“异步失败”其实源于脚本没设计好：
- 脚本开头加锁（如
flock -n），防止同一任务被多个 worker 并发触发 - 用
trap 'rm -f /tmp/backup.lock' EXIT确保异常退出时释放锁 - 输出结构化日志（如 JSON 行格式），方便 worker 解析进度或错误字段，而不是靠 grep “Done”
- 避免交互式命令（如
mysql未配my.cnf导致卡在密码提示），所有凭证通过文件或环境变量注入
真正难的不是启动一个进程，而是确保它在 PHP 生命周期外持续、可观测、可恢复地跑完。Process 组件只是工具链中一环，别让它背锅。
