Composer脚本中无法真正非阻塞运行PHP命令，因其默认同步执行且子进程易被SIGHUP终止；可靠方案是用nohup+setsid（Linux/macOS）或start /B cmd /C（Windows）彻底脱离父进程，或改用supervisord/systemd等专业进程管理器。
Composer 脚本里直接调用 php 命令会阻塞，怎么非阻塞运行？
Composer 的 scripts 默认是同步执行的，哪怕你在脚本里加了 & 或 nohup，PHP 进程仍会等待子进程结束（尤其在 Windows 或某些 shell 环境下）。这不是 Composer 本身的问题，而是 PHP 的 proc_open 和 shell 行为导致的。
真正可行的做法是绕过 PHP 的进程等待机制：
- 用
exec()+>/dev/null 2>&1 &（Linux/macOS），确保输出重定向且后台脱离父进程 - Windows 下必须用
start /B并配合cmd /C，否则窗口会弹出或卡住 - 避免用
shell_exec()或system()，它们默认等待完成
示例（composer.json）：
"scripts": {
"start-worker": "exec 'php artisan queue:work --daemon > /dev/null 2>&1 &'"
}
⚠️注意：exec 在 PHP 中默认被禁用（disable_functions），需确认服务器允许。
用 symfony/process 启动后台任务更可靠吗？
可以，但要注意它默认仍是同步等待。必须显式调用 start() 而非 run()，并手动 detach：
-
$process->start()是异步起点，但不自动 detach；需再调用$process->setIdleTimeout(0)防止超时中断 - Linux 下建议加
setEnv(['NO_COLOR' => '1'])避免 ANSI 控制符干扰日志 - 不能依赖
$process->isRunning()判断长期存活——它只反映启动瞬间状态，进程可能秒退
简短调用示例：
use Symfony\Component\Process\Process; $process = new Process(['php', 'artisan', 'horizon']); $process->start(); // 不要 $process->wait()
为什么 composer run-script 执行完就终止后台进程？
根本原因是：Composer 进程退出时，其子进程收到 SIGHUP（挂起信号），Linux 默认终止它们。即使你用了 &，也没脱离 session。
解决的关键是「完全脱离父进程控制」：
- Linux/macOS：用
nohup+setsid（比单纯&更彻底） - 必须重定向所有 stdio：
nohup php artisan schedule:run >/dev/null 2>&1 & - Windows：用
start /B cmd /C "php artisan ... >nul 2>&1"，/B表示无窗口，cmd /C提供独立 shell 环境
别信“加个 & 就后台了”——没 nohup 或 setsid，进程大概率随 composer 退出而死。
有没有更稳的替代方案，而不是硬塞命令到 Composer 脚本？
有。Composer 不是进程管理器，强行让它管后台任务容易失控。推荐分层处理：
- 把实际任务封装成独立可执行脚本（如
bin/start-queue.sh），用supervisord、systemd或pm2管理生命周期 - Composer 脚本只做「触发注册」：比如写一个
.env.running文件或调用curl http://localhost:8000/api/start-worker - 如果必须用 Composer 启动，至少加健康检查：用
ps aux | grep 'artisan queue:work'确认进程真活着，而非只看 exit code
复杂点在于：后台任务的错误不会回传到 Composer 输出里，日志必须单独配置路径，否则你会以为它跑着，其实早崩了。
