Composer如何在共享主机用_Composer虚拟主机部署方案【汇总】

在共享主机上直接跑 composer install，十有八九会卡住或报错。这不是配置问题，也不是运气不好，而是共享主机环境本身就有三个硬伤：proc_open() 被禁用、没有 Git、目录不可写。换句话说，你在本地能顺利执行的那套流程，上传到服务器上基本就跑不通。

所以问题的核心不在于“怎么配置”，而在于——根本不能在共享主机上执行 composer install。你需要换一个策略：在本地用同版本的 PHP 构建好 vendor/ 目录，然后整体上传，再用一个简单的 test-autoloader.php 来验证。

为什么 composer install 在共享主机上必报错

错误提示五花八门，但根因就两个：

• 进程创建被封锁：proc_open() has been disabled 或 command not found: git——主机通过 disable_functions 直接干掉了类似命令调用和外部进程创建的能力。
• 目录权限受限：Web 根目录（比如 ~/public_html/）默认不可写，你连 vendor/ 都创建不了，file_put_contents(./vendor/autoload.php): Permission denied 的错误自然会跳出来。
• Git 不存在：Composer 默认优先走 Git 克隆，但共享主机一般不装 Git。如果它还卡在 Cloning into ''，那就说明它没自动切换到 dist 包下载。
• 资源限制击倒 PHAR：memory_limit=64M 或 max_execution_time=30，直接让你的 PHAR 执行到一半就中断，甚至不留下任何日志。

这些错误几乎不可避免。所以正确的做法是：在本地用和生产环境相同的 PHP 版本，执行 composer install --no-dev --optimize-autoloader --prefer-dist --no-plugins，然后将 vendor/ 上传到服务器。

本地构建 vendor/ 必须加的参数

别拿本地开发环境随便跑 composer install，那大概率出问题。上传后报 Class not found，八成就是这一步没对齐：

• --no-dev：跳过 require-dev 里的包（比如 PHPUnit、phpstan）。它们在生产环境不仅没用，还可能因为 PHP 版本不兼容直接崩掉。
• --optimize-autoloader（或 -o）：生成 classmap 映射。加载速度快，而且不依赖 opcache.file_cache 这类共享主机常关闭的配置。
• 额外建议加 --prefer-dist --no-plugins：强制走 zip 包下载，避开 Git；禁用插件，防止某些钩子脚本因权限失败。

这样构建出来的 vendor/ 目录，才是真正为共享主机环境定制的。

上传后 Class not found 的真实原因

vendor 目录完整上传了，autoload.php 文件也在，但还是找不到类？大概率是路径或权限陷阱：

• 入口文件里写的是 require __DIR__.'/vendor/autoload.php';——如果项目不在 Web 根目录下（比如放在子目录或通过 alias 访问），这个相对路径会错。改用 require_once dirname(__DIR__).'/vendor/autoload.php'; 或结合 $_SERVER['DOCUMENT_ROOT'] 拼绝对路径。
• vendor/autoload.php 末尾包含硬编码绝对路径（比如 require '/home/user/xxx/vendor/composer/autoload_real.php'）：这说明本地构建时没清缓存。删掉整个 vendor/ 和 composer.lock，再重跑 composer install --no-dev -o。
• 上传后文件权限太严（比如 600），PHP 无法读取。上传前在本地执行 umask 002，或上传后用 FTP 批量设为 644/755。

怎么验证 vendor/ 真的能用

别等上线才踩坑。上传完立刻建个 test-autoloader.php 放到 Web 可访问目录下：

返回 bool(true) 才算过关。如果报错，优先检查三件事：PHP 版本是否与本地一致、autoload.php 路径是否写死、composer.lock 是否一起上传——漏掉任意一个，线上行为都不可控。