直接上传 vendor 目录及 autoload.php 是最可行方案,前提是 PHP 版本、扩展、文件权限、autoload.php 路径四者全部兼容;共享主机通常禁用 composer 执行,且需验证 opcache 配置以防类文件更新不生效。

直接把 vendor 目录连同 autoload.php 一起上传是最可行的方案,前提是本地环境与目标主机的 PHP 版本、扩展、文件权限兼容。
为什么不能在共享主机上运行 composer install
多数共享主机禁用 shell 访问或明确禁止执行 composer(尤其是 proc_open、exec 等函数被禁用),导致 composer install 直接失败,错误信息通常是:Command not found 或 proc_open() has been disabled。即使能上传 composer.phar,也大概率因内存限制或超时中断。
手动部署前必须验证的 4 个条件
缺一不可,否则上线后会报 Class not found 或 require(): failed to open stream:
-
PHP版本一致:检查本地php -v与主机控制面板或phpinfo()输出是否匹配(尤其注意7.4和8.0+的类型声明差异) -
扩展启用情况:比如mbstring、json、curl必须开启;某些包(如guzzlehttp/guzzle)还依赖openssl -
autoload.php路径正确:确认你的代码中require 'vendor/autoload.php';的相对路径与上传后的实际目录结构一致 -
vendor目录完整性:不要漏传vendor/composer/下的autoload_classmap.php、autoload_psr4.php等关键文件
如何最小化 vendor 体积并避免冲突
共享主机常有磁盘配额限制,且部分主机对 .git、tests、docs 目录敏感(可能触发安全扫描误报):
- 本地执行
composer install --no-dev --optimize-autoloader,跳过开发依赖并生成优化后的类映射 - 上传前删掉
vendor/、/tests vendor/、/docs vendor/(但保留/.git vendor/composer/) - 若只用到某个包的少数功能(如仅用
monolog/monolog写日志),可考虑改用单文件轻量替代(如psr/log+ 自定义写入器),避免整个vendor目录 - 注意
composer.lock不用上传,但它必须和本地vendor生成时完全对应——换言之,别在上传后又在本地改composer.json再重装
require_once __DIR__ . '/vendor/autoload.php';
use Monolog\Logger;
use Monolog\Handler\StreamHandler;
$logger = new Logger('app');
$logger->pushHandler(new StreamHandler(__DIR__ . '/logs/app.log', Logger::WARNING));
$logger->warning('Manual vendor deployed OK.');
最易被忽略的是 opcache.revalidate_freq 设置:有些共享主机设为 0(不检查文件更新),导致你替换了 vendor 里的类却仍加载旧缓存;这时需要联系主机商临时关闭 opcache,或改用 opcache_invalidate() 手动刷新(前提是该函数未被禁用)。










