配了中文镜像仍卡在Loading composer repositories或Downloading，主因是镜像链路未打穿：元数据源、dist包路径、并发策略、TLS复用四环缺一不可；必须验证config输出为完整JSON或带斜杠的HTTPS URL，且需清理vendor和composer.lock并重装。
配了中文镜像还卡在 Loading composer repositories 或 Downloading https://codeload.github.com/，不是网络抖动，是你没把镜像链路打穿——元数据源、dist 包路径、并发策略、TLS 复用这四环里漏掉任意一环，都会在骨干网波动时被放大成超时或重试。
确认当前生效的镜像源是否真走通
执行 composer config -g repo.packagist 只是第一步，输出必须是完整 JSON 对象（如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}）或带结尾斜杠的 HTTPS URL。空、null、或仍是 https://packagist.org，说明配置根本没落地。
- 常见静默失败原因：
repos.packagist（多一个s）、漏掉composer类型参数、URL 少末尾/、用了http:// - 项目根目录若存在
composer.json且含"repositories"字段，会完全屏蔽全局配置，优先级更高 - CI/CD 中以
www-data或root用户运行命令时，-g写入的是该用户家目录下的~/.composer/config.json，和你本地配置不互通
为什么测得快，但 composer install 还卡住
骨干网波动下，单点 curl -w "%{time_starttransfer}" 测包速度没意义。Composer 实际要串行请求：元数据 packages.json → 每个 provider 文件 → ZIP 包 → 校验 hash。任一环节 TLS 复用失败、DNS 缓存过期、镜像后端限流，整条链就卡死。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 用
curl -o /dev/null -s -w "%{time_starttransfer}\n" https://mirrors.aliyun.com/composer/packages.json测三次取中位数，超1.5秒的镜像别用 -
-vvv日志里出现302 Found，大概率是旧镜像（如 PHPComponer）已停服，重定向吃掉 300ms+ - 阿里云目前仍为 HTTP/1.1；清华源虽支持 HTTP/2，但需确认
curl -I --http2 https://mirrors.tuna.tsinghua.edu.cn/composer/返回HTTP/2 200才算真启用
http-max-concurrent-downloads 设多少才扛得住波动
新版 Composer（2.2+）只认 http-max-concurrent-downloads，parallel-downloads 已弃用且不报错——设了也白设。骨干网抖动时，并发太高反而触发底层 cURL 句柄耗尽或 DNS 解析排队。
- 推荐值：8～10；别超过 12，尤其 macOS 或企业内网环境下容易触发
file_get_contents(): SSL operation failed - 查当前值：
composer config -g http-max-concurrent-downloads；设新值：composer config -g http-max-concurrent-downloads 10 - 某些 CI 环境（如 GitHub Actions）默认并发较低，可额外加
--no-cache避免缓存干扰
最常被跳过的兜底动作：删 vendor 和 composer.lock
镜像配置再对，只要 composer.lock 里 dist.url 还是原始 GitHub 地址，Composer 就会继续直连 https://codeload.github.com/——这和镜像源完全无关，骨干网波动时首当其冲。
- 换源后必须执行：
rm -rf vendor composer.lock，再跑composer install --no-cache - 若日志里仍出现
Downloading https://api.github.com/，说明旧 lock 文件残留，或项目级repositories被误写成空数组覆盖了镜像 - 安全起见，CI 构建脚本开头加
composer clear-cache，并确保memory_limit足够（建议-1），禁用Xdebug
骨干网波动本身不可控，能控的是你的配置是否每一环都经得起验证——从 repo.packagist 的拼写，到 dist.url 的生成时机，再到并发下载的句柄上限，漏掉任何一个，波动就会变成故障。
