直接nohup composer install &会失败，因Composer默认交互式、依赖禁用的proc_open等函数且stderr不重定向；应改用nohup php -d disable_functions="" composer install --no-interaction 1>composer.log 2>&1 &并检查log末尾"Memory usage:"确认成功。
nohup php -d disable_functions= exec,system,shell_exec composer install & 为什么不能直接用？
直接 nohup composer install & 看似合理，但实际会失败或行为异常，原因有三：
-
composer install默认是交互式命令，遇到权限、镜像配置或依赖冲突时会停在终端等待输入，nohup无法提供 stdin，导致进程卡住或立即退出 - Composer 内部大量使用
proc_open()启动子进程（比如运行 post-install-cmd），而很多生产环境 PHP 配置禁用了exec、system等函数——这些禁用项不会报错，只会让子进程静默失败，最终表现为“安装卡住”或“vendor 目录不完整” -
nohup默认把 stdout/stderr 合并写入nohup.out，但 Composer 的关键错误（如网络超时、SSL 验证失败）全走 stderr，若没显式重定向，你根本看不到真实失败原因
真正可用的后台执行命令：带参数、重定向、容错检查
下面这条命令已在 Ubuntu 22.04 + PHP 8.2 + Composer 2.7.x 环境验证通过，适用于 CI/CD 或部署脚本：
nohup php -d disable_functions="" -d memory_limit=-1 composer install --no-interaction --no-ansi --no-progress 1>composer.log 2>&1 & echo $! > composer.pid
拆解关键点：
-
php -d disable_functions=""：临时清空禁用函数列表，确保proc_open、exec等能正常调用（注意：仅限当前命令生效，不修改 php.ini） -
--no-interaction：强制非交互模式，避免卡在 prompt 上 -
1>composer.log 2>&1：把 stdout 和 stderr 全部合并写入composer.log，而不是默认的nohup.out，方便后续 grep 错误 -
echo $! > composer.pid：记录刚启动的进程 PID 到文件，便于后续kill $(cat composer.pid)终止
如何判断 composer install 是否真的成功完成？
不能只看进程是否还在，因为 Composer 可能中途失败但子进程仍在（比如 post-install-cmd 卡死）。推荐用以下组合判断：
- 检查
composer.log末尾是否有Memory usage:行（Composer 成功完成的固定日志特征） - 运行
ls -l vendor/autoload.php，确认文件存在且可读 - 用
tail -n 20 composer.log | grep -E "(error|Error|failed|Failed)"过滤真实错误——注意不要用grep "ERROR"，因为 Composer 日志里[ERROR]是正常等级标识，不是失败信号 - 如果需要自动化检测，加一行：
grep -q "Memory usage:" composer.log && echo "success" || echo "failed"
为什么不用 screen 或 tmux 替代 nohup？
在服务器部署场景下，screen 和 tmux 不适合做 Composer 安装的守护方案，原因很实际：
-
screen -S install -X stuff类命令依赖 session 已存在，而首次运行时 session 还没创建，容易因 race condition 失败 - CI/CD 流水线（如 GitHub Actions、GitLab Runner）通常不提供伪终端（pty），
screen会直接报错Must be connected to a terminal -
tmux new-session -d虽然能后台建会话，但 Composer 进程一旦退出，tmux session 就自动销毁，无法保留日志供回溯 -
nohup是 POSIX 标准命令，所有 Linux 发行版原生支持，无额外依赖，更适合脚本化和最小化环境
真正要注意的是：Composer install 本身不是长期服务，它本就不该“守护”——它的正确姿势是一次性执行、明确成功或失败、日志可追溯。所谓“后台运行”，只是防止终端断开中断安装，不是要把它变成常驻进程。
