报错因虚拟主机禁用proc_open()等函数，应使用php composer.phar install –no-scripts –no-plugins –optimize-autoloader –classmap-authoritative；无ssh时须本地构建并严格匹配php环境后上传vendor/、composer.lock和composer.json。
proc_open() has been disabled 报错怎么办
绝大多数虚拟主机禁用 proc_open()、shell_exec() 等函数，直接运行 php composer.phar install 会空白、500 或报这个错误——不是你操作错了，是主机策略卡死的。
绕过它的唯一可靠方式是跳过所有需要执行外部进程的环节：
-
--no-scripts：跳过post-install-cmd、pre-autoload-dump等自定义脚本（90% 的 laravel/Lumen 项目不依赖它们启动） -
--no-plugins：禁用插件（比如hirak/prestissimo或某些私有仓库插件，内部常调用被禁函数） - 必须加
--optimize-autoloader和--classmap-authoritative：否则vendor/autoload.php可能加载失败或漏类——这不是可选项，是补救 autoloader 生效的必要组合
最终命令长这样：php composer.phar install --no-scripts --no-plugins --optimize-autoloader --classmap-authoritative
没有 SSH 权限时怎么装 vendor
连终端都打不开？那就别在服务器上折腾 composer 了，本地构建 + 全量上传是最稳的路径。
关键不是“能不能装”，而是“装出来的能不能跑”：
- 本地 PHP 版本、扩展（尤其是
ext-mbstring、ext-openssl）、架构（x86_64/ARM）必须和虚拟主机一致，否则上传后报undefined symbol或failed to open stream - 务必用
composer install --no-dev构建，vendor/少一半体积，避免虚拟主机磁盘超限 - 上传前检查
vendor/composer/autoload_classmap.php是否非空——空文件 = classmap 没生成成功，自动加载大概率失效 - 只传
vendor/、composer.lock、composer.json；删掉composer.phar、composer.lock.bak等冗余文件
入口文件里写好：require_once 'vendor/autoload.php';，路径别写错，权限设为 644。
哪些情况不能跳过 scripts
不是所有项目都能靠 --no-scripts 混过去。一旦依赖以下任一行为，就必须本地完整安装：
- 需要编译的扩展：比如
google/protobuf要跑protoc生成 PHP 类，ext-protobuf不在虚拟主机上，脚本就卡死 - 必须执行的 post-install-cmd：例如 Laravel 的
php artisan key:generate、symfony 的cache:warmup、或自定义配置生成逻辑 - 依赖
bin/下二进制文件：如phpunit、phinx，--no-scripts --no-plugins不会软链接它们，且没权限 chmod +x
这种项目，别省事。老老实实本地 composer install，确认 vendor/bin/ 里有对应文件、php artisan tinker 能进，再打包上传。
在线生成 vendor 包靠谱吗
像 https://composer.garden 这类服务，输入 composer.json 就给你打包好的 vendor.zip，听起来很香——但风险藏得深：
- 敏感项目代码（尤其含数据库配置、API Key 的
env或config/）可能被服务端日志记录或缓存 - 无法控制 PHP 版本和扩展，生成的
autoload_classmap.php在目标主机上可能失效 - 不支持
--no-dev或自定义平台配置，包体积大、兼容性差
只建议临时验证、小 demo 或公开开源项目用。生产环境、含业务逻辑的项目，一律本地构建。
最易被忽略的一点：composer.lock 文件必须和线上 vendor/ 完全匹配。哪怕只改了一行注释，下次想更新依赖时 composer update 就可能破坏一致性——所以每次上传 vendor，都要确保 lock 文件也同步过去。