composer超时需分层诊断：卡在resolving dependencies属dns或连通性问题，非timeout配置能解决；卡在downloading才调http.timeout（建议300～600秒）；卡在executing command才调process-timeout或composer_process_timeout（建议1200秒）。
Composer 网络超时不是“调大 timeout 就完事”的问题，它本质是分层失败——卡在 DNS、TLS 握手、HTTP 下载、子进程执行或 autoload 生成，每个环节对应的参数和排查手段完全不同。
卡在 Resolving dependencies 是网络层连不上，不是 timeout 的锅
这一步根本没发 HTTP 请求，只是查 packagist.org 域名解析和基础连通性。看到这行就别急着改 http.timeout，纯属白等。
- 运行
dig packagist.org或nslookup packagist.org，看是否返回国内镜像 IP（如阿里云镜像应为mirrors.aliyun.com对应的地址） - 手动测试：运行
curl -v https://mirrors.aliyun.com/composer/packages.json，观察卡在Resolving host、TCP connect还是TLS handshake - 公司内网常见于 DNS 污染或强制代理，临时换 DNS（如
114.114.114.114）或改/etc/hosts绑定镜像 IP 更快见效
卡在 Downloading https:// 是 http.timeout 真正该管的范围
这一阶段 Composer 正在拉取 packages.json 或 ZIP 包，失败报错通常是 cURL error 28、file_get_contents(): SSL operation failed 或反复重试后静默退出——这些全是 http.timeout 控制的边界。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 全局设值：运行
composer config -g http.timeout 600（单位秒，300～600 最常用） - 项目级覆盖更安全：在
composer.json的"config"段加"http.timeout": 600 - 注意：
process-timeout在这里完全无效；PHP CLI 自身的default_socket_timeout也会干扰，可临时绕过：php -d default_socket_timeout=600 $(which composer) install - 如果设到 600 还失败，大概率是 TLS 握手卡住（比如企业中间人代理未导入根证书），不是下载慢——此时
-vvv最后几行会显示error:14090086而非28
卡在 Executing command 或 The process timed out 是 process-timeout 的责任区
这时候 Composer 已经拿到包，正在解压、运行 post-install-cmd、git clone 私有仓库，甚至执行 php artisan optimize。错误里带 [RuntimeException] The process timed out 就是它。
- 全局配置已失效：新版 Composer 不再读取
composer config -g process-timeout，别信老教程 - 真正有效的只有环境变量：
COMPOSER_PROCESS_TIMEOUT=1200（Linux/macOS）或 Windows 系统变量 - 项目级推荐写进
composer.json："process-timeout": 1200，优先级高且不污染全局 - 私有 Git 仓库常因 SSH 超时卡死，顺手加
"github-protocols": ["https"]强制走 HTTPS，避免触发 git 协议被防火墙拦截
换了镜像还超时？先确认镜像真生效，再盯住并发和协议
很多人设了阿里云镜像，但 composer config -g repos.packagist 输出仍是 packagist.org，或者项目 composer.json 里硬编码了 repositories 字段，把全局镜像覆盖掉了。
- 验证镜像是否生效：运行
composer config -g repos.packagist，输出必须是{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 禁用并行下载减压：
composer config -g concurrent-connections 1，尤其在 CI 或低带宽环境很有效 - 强制 dist 包而非源码：
"preferred-install": {"*": "dist"}，避免触发git clone（它有自己的超时逻辑，且不响应process-timeout） - CI 流水线中，
COMPOSER_PROCESS_TIMEOUT必须作为环境变量注入，不能只靠命令行参数——容器重启后配置就丢了
最易被忽略的一点：http.timeout 和 process-timeout 是两条平行线，一个管网络请求生命周期，一个管本地命令执行时长。混着调、只调一个、或误以为 --timeout=600 能解决所有卡顿，都会让问题拖得更久。看 -vvv 最后一行停在哪，比猜更快。
