直接上传 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/<package>/tests、vendor/<package>/docs、vendor/<package>/.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() 手动刷新（前提是该函数未被禁用）。
