必须先确认镜像已正确生效，composer config -g repo.packagist 输出须为 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；若为空、null 或仍为 packagist.org，则调大 timeout 无效。
composer timeout 设置不解决镜像卡顿问题
国内 Composer 卡在 Loading composer repositories with package information 或 Downloading，99% 不是 timeout 设置太小，而是根本没走镜像源——timeout 只控制单次 HTTP 请求等待时长，但若请求发向了 packagist.org 这个物理距离远、TLS 握手慢、无 CDN 的地址，再调大 timeout 也只是让失败来得更晚。
必须先确认镜像已正确生效：composer config -g repo.packagist 输出必须是类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整 JSON；空、null、或仍显示 packagist.org，说明 timeout 再怎么调都白搭。
哪些 timeout 配置真有用、哪些纯属干扰
Composer 自身有三个 timeout 相关配置，但作用范围完全不同：
-
github-oauth.github.com和gitlab-token类凭据不影响包下载，只影响私有仓库认证 -
process-timeout控制脚本执行（如 post-install-cmd）超时，和网络无关 -
http-basic是认证配置，不是 timeout
真正相关的只有两个：
-
github-protocols：指定 Git 克隆协议（https/ssh），影响--prefer-source场景，和镜像下载无关 -
secure-http：强制 HTTPS，设为false可绕过证书校验（仅限内网可信环境），但它不是 timeout，只是开关
Composer 没有全局 timeout 配置项。所谓 “设置 timeout”，实际是误传——你搜到的 composer config -g github-protocols https 或 process-timeout 300，对镜像加速毫无帮助。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
镜像 + 网络环境适配才是关键
当镜像已正确配置但仍出现超时类报错（如 Curl error: Operation timed out），问题大概率出在底层网络链路，而非 Composer 参数：
- 企业防火墙或 CI 宿主机根证书过期，导致与
mirrors.aliyun.com的 TLS 握手失败：运行curl -I https://mirrors.aliyun.com/composer/packages.json验证是否返回200 - 某些旧系统（CentOS 6、Jenkins slave 镜像）ca-certificates 版本太老：执行
sudo update-ca-certificates（Debian/Ubuntu）或sudo yum update ca-certificates（RHEL/CentOS） - CI 环境中
secure-http false可临时规避证书问题，但必须配合镜像配置一起用，单独设它无效 - 别信“加 -vvv 就能看到 timeout 被触发”——日志里
Resolving dependencies卡住几十秒，是 PHP 解析约束逻辑慢，和网络 timeout 无关
换源后首次 install 必须清缓存 & 删 lock
镜像地址改了，但 composer.lock 里还记着 packagist.org 的原始 dist URL，vendor/ 下也残留旧元数据——Composer 会优先复用这些，导致“看似换源，实则仍走原站”。
必须执行三步：
composer clear-cache- 手动删掉项目下的
vendor/和composer.lock - 再跑
composer install -vvv，观察日志中请求域名是否变成mirrors.aliyun.com
跳过任何一步，哪怕镜像命令敲得再标准，也大概率继续卡在 loading 或 downloading。这是最常被跳过的实操环节。
