Composer 中文环境超时主因是 http.timeout 和 process-timeout 双参数过短且镜像未生效，需同步配置、分别验证、逐层排查；PHP CLI 下 max_execution_time 默认为0，Web 模式才触发该限制。
Composer 在中文环境下进程超时中断，90% 以上不是 PHP 执行时间限制，而是 http.timeout 和 process-timeout 两个独立参数同时过短，且镜像源未真正生效——必须同步调、分别验、逐层排。
为什么改了 max_execution_time 还报超时？
PHP CLI 模式下 max_execution_time 默认为 0（不限制），Fatal error: Maximum execution time of 30 seconds exceeded 只会出现在 Web SAPI（如 Apache/Nginx）里错误地用浏览器或 curl 调用 php composer.phar install。你看到的超时，100% 是 Composer 自身的两层超时机制在起作用：
-
http.timeout：控制单次 HTTP 请求（DNS + TLS 握手 + 下载 body）总耗时，默认 300 秒 -
process-timeout：控制整个命令生命周期（含git clone、解压、post-install-cmd），默认也是 300 秒 - 二者互不干扰；只改一个，失败概率仍高于 80%
怎么验证 http.timeout 和 process-timeout 是否真生效？
别信配置命令的返回，要查实际写入值：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer config -g http.timeout，输出必须是数字（如600），不能为空或null - 运行
composer config -g process-timeout，同理必须有非空数值 - 若输出为空，说明被项目级
composer.json中的"process-timeout"覆盖，需手动删掉该字段再试 - 验证镜像是否走通更关键：执行
curl -I https://mirrors.aliyun.com/composer/packages.json，应秒回HTTP/2 200；若超时或404，说明 DNS、代理或防火墙已阻断底层连接
国内环境推荐的最小有效组合参数
阿里云/腾讯云镜像实测稳定阈值（适用于 Composer 2.2+）：
- 全局 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 - 注意：
http-basic-timeout已废弃，http-timeout是旧别名，新版本只认http.timeout
镜像没生效？优先检查这三处硬性覆盖
很多人设了全局镜像却仍连 packagist.org，问题不在超时参数，而在配置被静默覆盖：
- 项目级
composer.json中的repositories字段会彻底屏蔽全局镜像；检查是否硬编码了"url": "https://packagist.org"或拼写错误的镜像地址 - 全局配置中用了
repos.packagist.org.url这类旧写法，正确格式是repo.packagist（注意没有.org），且末尾必须带composer类型标识：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI 环境中未启用缓存（如 GitHub Actions 未声明
cache: $HOME/.composer/cache），每次都是干净容器，DNS 和 TLS 握手开销被放大，再大的超时也扛不住反复初始化
最易被忽略的是：镜像源地址末尾是否带斜杠、type 字段是否拼错、以及私有包是否因未单独配置 repositories 而 fallback 到官方源卡死——这些都比调超时更优先排查。
