直接nohup composer install &必然失败，因Composer默认交互式、依赖proc_open()且关键错误全走stderr；须用nohup php -d disable_functions="" composer install --no-interaction 1>composer.log 2>&1 &并检查log末尾"Memory usage:"确认成功。
composer install 后台运行失败的三个硬伤
直接 nohup composer install & 必然出问题，不是“可能失败”，而是设计上就卡死：Composer 默认交互式、依赖 proc_open()、关键错误全走 stderr。这三处不处理，进程要么挂住不动，要么静默退出，nohup.out 里连错误都看不到。
-
composer install遇到权限确认、镜像切换或冲突提示时会停在stdin等输入，nohup不提供终端，直接僵住 - 内部大量调用
proc_open()执行post-install-cmd等命令，但生产环境 PHP 常禁用exec、system—— 这些函数被禁后不报错，子进程无声失败，vendor/缺文件却没提示 -
nohup默认只重定向stdout，而 Composer 的 SSL 错误、DNS 超时、403 权限拒绝等全打在stderr，不显式重定向就等于“盲跑”
代理配置必须 http-proxy 和 https-proxy 同时生效
只配 http-proxy 是无效的，Packagist 和所有主流仓库走 HTTPS，而 Composer 对协议路由是严格分离的：http-proxy 只管 HTTP 请求，https-proxy 才负责建立 CONNECT 隧道。漏掉任一字段，HTTPS 请求就 fallback 到直连，现象是卡在 Loading composer repositories，无报错、无超时提示，最终静默失败。
-
https-proxy的值必须是http://开头（哪怕代理本身监听 TLS 端口），填https://或缺协议头都会导致隧道建立失败 - 密码含
@、/、:必须 URL 编码，例如pa@ss/word→pa%40ss%2Fword，可用php -r "echo rawurlencode('pa@ss/word');"快速生成 - 验证是否生效：运行
composer config -g --list | grep -E "(http|https)-proxy"，两行都存在且格式正确才算配齐
后台执行命令必须带 disable_functions 清空和日志闭环
真正能落地的命令不是“加个 & 就完事”，而是要绕过 PHP 环境限制、关闭交互、收拢输出、留下可验证痕迹。下面这条已在 Ubuntu 22.04 + PHP 8.2 + Composer 2.7.x 验证通过：
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()可用（仅当前命令生效，不影响全局） -
--no-interaction强制非交互，避免任何等待输入场景；--no-ansi和--no-progress减少日志噪音，便于grep定位失败 -
1>composer.log 2>&1把全部输出合并进composer.log，而不是默认的nohup.out，后续排查只看这一个文件 -
echo $! > composer.pid记录 PID，方便后续kill $(cat composer.pid)终止，比ps aux | grep composer更可靠
判断是否成功不能只看进程是否存在
进程还在 ≠ 安装成功。Composer 可能卡在 post-install-cmd 里某个子命令（比如 php artisan optimize 内存溢出），主进程没退出但 vendor/autoload.php 没生成或不完整。必须组合验证：
- 检查
composer.log末尾是否有Memory usage:行——这是 Composer 成功完成的唯一稳定日志特征 - 运行
ls -l vendor/autoload.php，确认文件存在、可读、mtime 是本次运行时间 - 用
tail -n 20 composer.log | grep -E "(error|Error|failed|Failed)"过滤真实错误；注意别用grep "ERROR"，因为[ERROR]是 Composer 正常日志等级标识，不是失败信号
最常被忽略的是：代理配对了、命令写全了、日志也看了，但没检查 composer.lock 是否被并发写坏。多个 composer install 同时跑，不加 flock 锁定 composer.lock，会导致 vendor/ 目录状态混乱——这不是网络或代理问题，是部署流程缺陷。
