Composer install 触发 PHP 超时主因是网络延迟与默认配置不当，而非单纯执行时间不足；应换国内镜像源、禁用官方源回退、启用缓存、关闭非必要功能并正确配置 CLI 模式下的 max_execution_time 和 memory_limit。
为什么 composer install 会触发 PHP 超时？
PHP 默认的 max_execution_time 是 30 秒，而 Composer 在解析依赖、下载包、解压、生成 autoload 文件时可能卡在某一步（比如从 packagist.org 拉取元数据），导致脚本超时中断。这不是 Composer 本身报错，而是 PHP 强制终止了进程，错误信息通常是：Fatal error: Maximum execution time of 30 seconds exceeded。
直接调高 max_execution_time 只是掩耳盗铃——慢的根本原因是网络和默认配置，不是 PHP 限制本身。
换镜像源 + 关闭 Packagist 自动回退
国内直连 packagist.org 延迟高、丢包率高，Composer 默认会尝试官方源失败后才切镜像，这个“自动回退”过程本身就耗时且不可控。
- 运行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（阿里云镜像）或https://packagist.phpcomposer.com（已停用，不推荐） - 必须加
-g全局设置，否则项目级配置可能被composer.json中的repositories覆盖 - 执行
composer config -g repos.packagist false彻底禁用官方源回退，避免无谓等待 - 镜像源只加速元数据（
packages.json），实际 ZIP 包仍走 GitHub/GitLab，所以还需配合COMPOSER_HOME缓存优化
启用缓存 + 禁用不必要的功能
Composer 默认每次都会重新解析整个依赖图并检查更新，对 CI 或重复部署场景极不友好。
立即学习“PHP免费学习笔记（深入）”；
- 确保
COMPOSER_CACHE_DIR指向有读写权限的路径（如/tmp/composer-cache），避免反复下载相同 ZIP - 加
--no-interaction --no-ansi --optimize-autoloader --no-progress参数：关闭交互提示、颜色输出、autoload 优化（生成更高效的vendor/autoload.php）、进度条（减少 I/O） - 生产环境务必用
--no-dev，跳过require-dev下的包（如 PHPUnit、phpstan），能减少 30%~60% 的依赖解析时间 - 避免在 Docker 构建中反复
rm -rf vendor && composer install，应利用分层缓存保留vendor/和composer.lock
PHP 运行时参数不能只靠 ini_set()
很多人在 composer.phar 同目录放 php.ini 或写 ini_set('max_execution_time', 0)，但没用——Composer 是命令行工具，走的是 CLI SAPI，不读 Web 用的 php.ini，也不受脚本内 ini_set() 影响（CLI 模式下多数配置项是只读的）。
- 正确做法是：用
php -d max_execution_time=0 /path/to/composer.phar install - 或者修改 CLI 专用的 php.ini（通过
php -i | grep "Loaded Configuration File"找到路径），设max_execution_time = 0和memory_limit = -1（Composer 解析大项目常爆内存） -
memory_limit比超时更常成为瓶颈，尤其在composer update时，建议至少设为2G
真正卡住的地方往往不在 PHP 侧，而在 DNS 解析、TLS 握手、HTTP 重试逻辑。调参只是辅助，镜像 + 缓存 + 参数关闭才是组合拳。漏掉任意一环，都可能让“调大超时”变成等更久的假安心。
