共享主机上无法运行composer install，因主机禁用exec/proc_open且public_html不可写；唯一可行方案是本地构建vendor后上传，需PHP版本一致、加--no-dev--optimize-autoloader、验证autoload路径并上传composer.lock。
想在共享主机上直接运行 composer install？这个念头可以打消了。问题通常不在于配置，而在于共享主机的“天性”——绝大多数服务商都会禁用 exec、proc_open 这类关键函数，同时将 public_html 这类Web根目录设为只读。结果就是，生成 vendor 目录的尝试几乎必然失败。那么，靠谱的路径只剩下一条：在本地环境构建完整的 vendor/ 目录，然后完整地上传到服务器。
为什么在共享主机上运行 composer install 几乎必败
报错信息可能五花八门，但根源其实非常一致：主机环境在进程执行能力和文件系统权限上施加了双重枷锁。
proc_open() has been disabled或command not found：这是最直接的信号，意味着主机的PHP配置通过disable_functions明确封杀了进程创建函数。file_put_contents(./vendor/autoload.php): Permission denied：这表明Web根目录（例如~/public_html/）通常被设置为只读，Composer连创建vendor/目录的权限都没有。Cloning into ''卡住或失败：许多共享主机并未安装Git，而Composer默认会优先尝试使用Git克隆代码库，而不是下载打包好的dist文件。- 500错误且无日志：这往往是资源限制导致的“静默死亡”，比如
memory_limit=64M或max_execution_time=30的设置，足以让Composer的PHAR包执行过程被中途终止。
本地构建 vendor 的实操要点
别以为这只是简单的“复制粘贴”。从本地到线上，有几个关键参数和环境必须严丝合缝地对齐，否则后患无穷。
- PHP版本必须对齐：本地的PHP版本务必与共享主机保持一致，至少主版本要相同。如果主机跑的是PHP 8.1，就别用本地的PHP 8.3来执行
composer install。 - 使用正确的安装参数：执行时务必加上
--no-dev --optimize-autoloader（可简写为-o）。前者跳过开发依赖，后者生成优化的classmap映射，减少对opcache.file_cache的依赖。 - 推荐附加参数：建议再加上
--no-plugins --prefer-dist。这能禁用可能引发问题的插件（例如某些资源管理插件），并强制Composer下载zip压缩包，彻底避开对Git的依赖。 - 清理composer.json：上传前，最好删掉
composer.json中所有"scripts"定义、私有的"repositories"源，以及"config"下可能包含全局绝对路径的设置（比如bin-dir）。 - 构建前彻底清理：运行安装命令前，先执行
composer clear-cache清空本地缓存，然后删除项目下的vendor/目录和composer.lock文件，最后再执行composer install -o --no-dev进行全新构建。
上传后 Class not found 的真实原因和验证方法
文件明明传上去了，却报“Class not found”？问题往往不在文件缺失，而是自动加载器的路径“写死”了，或者加载逻辑在服务器环境下失效了。
- 检查autoload.php的路径：打开
vendor/autoload.php，看开头几行。如果发现类似require '/home/xxx/vendor/composer/autoload_real.php'的绝对路径，说明构建时的路径缓存没清理干净。需要在本地重新运行composer dump-autoload -o。 - 确认入口文件写法：在项目的入口文件（如
index.php）中，使用require_once __DIR__ . '/../vendor/autoload.php';这种基于__DIR__的相对路径，通常比简单的require 'vendor/autoload.php';更可靠。 - 上传后立即验证：上传完成后，在Web可访问的目录下创建一个简单的测试文件，例如
test-autoloader.php：通过浏览器访问这个文件，如果能正常输出“Autoloader loaded”，就说明自动加载器的路径和文件权限基本没问题。
- 检查目录权限：确认
vendor/目录及其内容的权限。通常目录设为755，文件设为644。如果仍有问题，可以尝试将目录权限改为775（部分主机对755权限下的目录遍历仍有额外限制）。
没有 SSH 时，别碰 composer.phar 自动安装
有人可能会想：既然不能在线安装，那我上传 composer.phar 文件，然后在服务器上用 php composer.phar install 执行总可以吧？事实上，这条路往往更糟。
- 即使成功上传了PHAR文件，执行
php composer.phar install这个命令本身，就会触发proc_open、向临时目录写入、调用Git等同样被主机禁止的行为。 - 函数
sys_get_temp_dir()返回的临时目录路径（如/tmp）在共享主机环境下经常是不可写的，这会导致PHAR文件自身解包失败。 - 更极端的情况是，部分主机连
php -v这样的基础CLI命令都无法执行或返回空，这意味着命令行接口完全不可用，php composer.phar自然也无从谈起。 - 需要警惕的是，控制面板里那些所谓的“PHP脚本执行”或“Cron任务”功能（比如cPanel提供的），其本质通常是CGI模式，并不支持完整的命令行上下文，
exec类的函数在其中会静默失败。
最后，还有一个极易被忽略的关键点：composer.lock 文件必须和 vendor/ 目录一同上传。并且，lock文件中的依赖版本必须与线上PHP版本兼容。否则，即便自动加载成功，代码在实例化某个类时，也可能因为PHP语法版本不兼容而直接抛出 syntax error，有时甚至连明确的错误提示都不会有。
