composer超时主因是curl和子进程层超时，非php cli的max_execution_time；需同步调大http.timeout、process-timeout并验证镜像生效，国内环境推荐设为600秒和1800秒。
PHP CLI 的 max_execution_time 不是 Composer 的瓶颈
Composer 是命令行工具，走的是 PHP CLI SAPI，max_execution_time 在 CLI 模式下默认为 0（不限制），根本不会触发 “PHP 执行超时” 错误。你看到的 Fatal error: Maximum execution time of 30 seconds exceeded 只可能出现在 Web SAPI（如 Apache/Nginx）里运行 composer.phar，这属于错误使用方式——别用浏览器或 curl 调用 php composer.phar install，必须在终端直接执行。
真正卡住的是 cURL 层和子进程层超时
中文环境下 Composer 中断，90% 以上不是 PHP 限制，而是两层独立超时叠加：
-
http.timeout（默认 300 秒）：控制 DNS + 连接 + 下载整个 HTTP 请求周期，对镜像源响应慢、大 ZIP 包传输慢最敏感 -
process-timeout（默认 300 秒）：控制git clone、unzip、post-install-cmd等 shell 子进程执行时间，私有库或含二进制的包极易触达
两者互不干扰，改错一个就白调。验证是否生效：composer config -g http.timeout 和 composer config -g process-timeout 必须都输出非空数字。
国内环境必须同步调大 timeout 和 process-timeout
只改其中一个，大概率仍失败。推荐组合（适用于阿里云/清华镜像）：
- 全局 HTTP 超时：
composer config -g http.timeout 600（10 分钟） - 全局连接超时：
composer config -g http.connect-timeout 60（避免弱网反复握手） - 全局进程超时：
composer config -g process-timeout 1800（30 分钟） - 启用重试（Composer 2.2+）：
composer config -g http.max-retries 3
注意：composer config -g process-timeout 在 Composer ^2.2+ 已废弃写入配置文件，但实际仍有效；若输出为空，说明被项目级 composer.json 中的 "process-timeout" 覆盖，需优先检查该项目配置。
镜像没生效？curl -I 比 config 命令更可靠
composer config -g repos.packagist 输出镜像 URL 不代表请求真走那里——项目根目录下的 composer.json 若硬编码了 "repositories"，会彻底屏蔽全局镜像。更直接的验证方式：
- 手动测镜像连通性：
curl -I https://mirrors.aliyun.com/composer/packages.json，必须秒回HTTP/2 200 - 若超时或返回
404，问题不在 Composer，而在本地 DNS（试试119.29.29.29）、代理或防火墙 - 加
-v运行composer install，看日志里实际请求的 URL 是不是镜像地址
最容易被忽略的是：镜像只加速元数据（packages.json），ZIP 包仍从 GitHub/GitLab 下载。如果卡在 Downloading https://api.github.com/...，得单独优化 Git 或换 Gitee 镜像代理。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
