共享主机上 composer 失败因禁用 proc_open 等函数、限制 allow_url_fopen 且缺 openssl；应本地执行 install 后上传 vendor，避免服务器端运行 composer。
共享主机上运行 composer 为什么失败？
因为绝大多数共享主机默认禁用 proc_open、exec、shell_exec 等函数，而 composer 安装依赖时会调用 git、unzip 或 tar —— 这些操作在无 shell 权限或函数被禁用时直接报错：proc_open() has been disabled for security reasons。
共享主机的 PHP 通常还限制了 allow_url_fopen（影响包元数据下载），且不提供 openssl 扩展（导致 HTTPS 请求失败）。这些不是配置问题，是服务商主动锁死的权限边界。
不用 root，怎么让 composer install 跑起来？
核心思路：绕过主机上的 PHP 运行时限制，把耗权限的操作「移出服务器」。
- 在本地完整执行
composer install --no-dev --optimize-autoloader，生成可部署的vendor/目录和composer.lock - 把整个项目（含
vendor/）压缩上传，跳过服务器端任何composer命令 - 若必须更新依赖（比如线上修一个小 patch），改用
composer install --no-plugins --no-scripts，并确保vendor/autoload.php不依赖未启用的扩展 - 避免使用需要 Git 克隆的包（如
"dev-master"），全部锁定到具体 tag 或 commit hash，否则仍会触发git clone
composer.json 里哪些配置会加剧共享主机兼容性问题？
这些写法在共享主机上极易翻车，得提前剪掉：
-
"type": "package"+"dist"指向 zip URL？检查该 URL 是否能被主机 PHP 的file_get_contents()访问（常因 SSL/TLS 版本低或证书校验失败而静默失败） -
"scripts"里调用php或npm？删掉，或改成空数组："scripts": {} -
"config": { "process-timeout": 0 }？别加，超时控制本身依赖被禁函数，反而让错误更隐蔽 -
"platform": { "php": "8.1.0" }？确认主机实际 PHP 版本，不匹配会导致composer install拒绝生成 autoloader
上传 vendor 后仍报 Class not found？
不是 composer 没跑完，而是 autoloader 加载路径或权限出了岔子：
- 检查
vendor/autoload.php文件权限是否为644（有些主机拒绝执行755的 PHP 文件） - 确保
vendor/composer/autoload_classmap.php和autoload_static.php存在且非空——若本地用了--classmap-authoritative，但上传漏了某个文件，就会静默跳过类注册 - 如果用的是
psr-4映射，注意主机文件系统是否区分大小写（某些 Linux 共享环境实际是 case-sensitive，但开发机是 macOS 默认不区分）
共享主机的“不可控”不在文档里，而在 phpinfo() 里没列出来的那些 disabled 函数、被截断的 error_log、以及悄无声息跳过的 hooks。能本地做完的事，就别指望它在线上补全。
