共享主机上 Composer 安装失败主因是内存不足或超时，应优先本地构建 vendor 并上传；次选调低资源占用（如 --no-dev、--no-scripts）、禁用并行、强制 dist 安装或优化 autoloader。
在共享主机上用 Composer 安装或更新依赖时，常因内存不足（如 Allowed memory size exhausted）或超时（Maximum execution time exceeded）失败。根本原因是共享环境限制严格，且 Composer 默认行为较“重”。解决方向是减小资源占用、绕过运行时限制、或提前本地处理。
降低 Composer 内存和 CPU 消耗
Composer 8.x+ 默认启用并行安装和更激进的依赖解析，容易触发内存峰值。可手动调低资源使用：
- 加
--no-scripts --no-autoloader参数跳过脚本执行和自动加载器生成（尤其适合仅部署，不需立即运行） - 用
--no-plugins禁用插件，避免额外开销 - 设置内存限制：运行前加
COMPOSER_MEMORY_LIMIT=-1（Linux/macOS）或set COMPOSER_MEMORY_LIMIT=-1（Windows），让 PHP 不强制限制；若仍报错，改用COMPOSER_MEMORY_LIMIT=512M明确设上限 - 禁用并行安装：
composer install --no-parallel，减少并发进程数
绕过共享主机的执行时间限制
很多共享主机对单个 PHP 进程设了 30–60 秒超时，而 Composer 可能卡在下载或解压大包（如 Laravel、Symfony 全集）。这时不能靠延长 timeout（通常不可改），而要换方式：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 用
composer install --prefer-dist强制走压缩包安装（比--prefer-source快得多，也省内存） - 提前在本地运行
composer install --no-dev，再把整个vendor/文件夹上传——这是最稳定、最常用的做法 - 若必须在线运行，尝试分步：先
composer update --lock更新锁文件，再composer install，避免一次解析全部依赖
优化 autoloader 和减少 vendor 体积
vendor 目录过大不仅拖慢 Composer，还可能触发磁盘配额或 FTP 上传失败。精简它能间接缓解资源压力：
- 运行
composer install --no-dev（上线环境绝不装 dev 依赖） - 启用优化自动加载：
composer dump-autoload --optimize --classmap-authoritative，生成扁平 classmap，减少运行时查找开销 - 删掉文档、测试、未用扩展：用
composer install --no-dev --optimize-autoloader --classmap-authoritative一步到位 - 检查是否误装了全量框架（如
laravel/framework+laravel/tinker+laravel/sail），按需保留核心组件
替代方案：离线构建或使用 build 工具
如果上述方法仍不稳定，说明主机限制已超出 Composer 友好范围。此时应彻底脱离在线执行：
- 在本地或 VPS 上完整
composer install --no-dev，压缩vendor/后上传，再通过 FTP 或主机控制面板解压 - 用
composer archive打包项目（含 vendor），适合频繁部署 - 某些主机支持 SSH + 自定义 PHP CLI 版本，可尝试切换到更高内存/更长 timeout 的 PHP CLI（如 PHP 8.1 CLI vs PHP 8.1 CGI），有时差异显著
基本上就这些。共享主机不是为 Composer 设计的，所以重点不在“硬扛限制”，而在“避开限制”。本地构建 + 上传 vendor 是最稳妥的路径，既快又可控。
