Composer 本身不支持真正后台运行，composer run xxx & 或 nohup 仅使主进程后台化，无法守护子进程；长期任务（如队列、HTTP 服务）必须由 supervisord/systemd 等进程管理工具托管，确保自动重启、日志记录与资源控制。
Composer 本身不支持后台运行脚本
直接执行 composer run xxx & 或加 nohup 并不能让 Composer 脚本“真正后台化”——因为 composer run 只是启动一个短命的 PHP 进程来执行命令，它自己不是守护进程，也不管理子进程生命周期。所谓“后台运行”，实际要解决的是：如何让脚本所调用的长期任务（如队列 worker、HTTP 服务、监听器）稳定驻留、自动恢复、资源可控。
真正该后台化的不是 Composer，而是你脚本里调用的命令
常见误操作：在 composer.json 的 scripts 里写 "serve": "php -S localhost:8000"，然后 composer serve & —— 这样只是把 PHP 内置服务器扔进后台，但没做进程守护，一旦崩溃就没了，也无日志、无重启、无资源限制。
- PHP 内置服务器适合开发调试，生产环境必须换 Swoole / RoadRunner 或 Nginx + PHP-FPM
- 队列 worker（如
php artisan queue:work）需配合supervisord或systemd管理，不能裸跑 - 定时调度（
schedule:run）应由系统 crontab 触发，而非靠 Composer 启动一个常驻进程 - 检查进程是否真在后台：
ps aux | grep -E "(queue:work|horizon|schedule:run)"，看 CMD 列是否带--daemon或被supervisord包裹
用 supervisord 管理 PHP 后台进程最稳妥
Supervisor 是成熟、轻量、配置直观的进程管理工具，比自己写 shell 脚本或依赖框架内置守护更可靠。它不依赖 Composer，但可与 Composer 安装的包协同工作（比如 Laravel Horizon 就推荐用它托管）。
- 安装：
composer require supervisorphp/supervisor（仅提供 PHP API 封装，仍需系统级supervisord服务） - 关键配置项（
/etc/supervisor/conf.d/myapp.conf）：[program:myapp-queue] command=php /var/www/artisan queue:work --sleep=3 --tries=3 directory=/var/www autostart=true autorestart=true user=www-data redirect_stderr=true stdout_logfile=/var/log/myapp-queue.log
-
autorestart=unexpected比true更安全，避免因信号退出（如 deploy 时 reload）被误判为崩溃 - 不要在
command中写cd && php，用directory字段指定工作目录即可
为什么别用 & 或 nohup 直接跑 Composer 脚本
看似简单，但埋下多个隐患：
-
nohup composer run queue-start &：如果queue-start脚本里只是php artisan queue:work，那这个进程没有父进程管理，OOM 时会被 kernel 杀掉，且日志无法轮转 - Shell 后台作业受终端 session 控制，SSH 断开后可能被 SIGHUP 终止（即使加了
nohup，某些 shell 配置仍会干扰） - 无法统一查看状态：
supervisorctl status可查全部 worker；而ps aux | grep易漏匹配、难区分实例 - 资源失控：没设
memory_limit或 CPU 限制，单个 worker 吃光内存会拖垮整机
真正需要关注的，从来不是“怎么让 Composer 后台跑”，而是“我启动的那个长期命令，有没有被正确托管”。Composer 只负责把代码准备好，剩下的事它不管，也不该它管。
