国内Composer镜像源选择需匹配网络环境、项目规模和CI/CD流程；阿里云、腾讯云、华为云可用性相近（99.2%–99.5%），但元数据响应、dist包CDN路由、同步延迟才是影响composer update卡顿的关键瓶颈。
国内 Composer 镜像源不是“换一个就快”，而是要匹配你的网络环境、项目规模和 CI/CD 流程。阿里云、腾讯云、华为云三者在可用性上差异极小（99.2%–99.5%），但元数据响应、dist 包 CDN 路由、同步延迟这三项，才是影响你 composer update 卡顿与否的真正瓶颈。
怎么看镜像源实际响应速度
别只信 ping 延迟——ping 测的是 ICMP，而 Composer 走的是 HTTPS + cURL，受 DNS 解析、TLS 握手、CDN 节点调度影响更大。真实体验取决于 packages.json 的首字节响应时间（TTFB）。
- 快速验证命令：
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://mirrors.aliyun.com/composer/packages.json - 腾讯云镜像在华南节点常有更低 TTFB（实测平均 120ms），但华东用户可能反而比阿里云慢 30–50ms
- 华为云对 IPv6 支持更激进，若你本地网络 IPv6 不稳，
COMPOSER_IPV4=1 composer install可能直接提速一倍 - 阿里云镜像的
packages.json是 gzip 压缩+边缘缓存，体积比官方小 68%，这对低带宽 CI 环境很关键
同步延迟怎么查，为什么它比“快”更重要
镜像再快，如果新发布的包还没同步，composer require vendor/package:dev-main 就会 fallback 到官方源或报 404。这不是超时问题，是数据缺失。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 查同步状态最准的方式：访问镜像的
/packages.json文件末尾，看"lastUpdated"时间戳，对比https://packagist.org/packages.json的同字段 - 阿里云通常延迟 ≤ 90 秒；腾讯云在大版本发布高峰（如 Laravel 12 RC）曾出现过 3–5 分钟延迟；华为云偶发因 CDN 缓存策略导致
dev-分支元数据更新滞后 - 如果你项目重度依赖 nightly 或 dev 分支，建议加个脚本定期 curl 对比，而不是靠人工感知
为什么配了镜像，composer install 还卡 30 秒
这不是镜像慢，是 Composer 默认行为：单个源请求失败前，会完整等待 30 秒超时（含重试），才尝试下一个源——前提是它被配置为 fallback 源。
-
repo.packagist是单值字段，composer config -g repo.packagist composer xxx写两次，第二次必然覆盖第一次 - 真要 fallback，必须改项目级
composer.json，显式声明repositories数组，并设"packagist.org": false - 即使这样，Composer 也不会“连接失败立刻切”，而是等完整超时后才查下一个源；所以更有效的是全局调大超时：
composer config -g http.timeout 600 - 并发下载
parallel-downloads只加速 ZIP 包拉取，对元数据阶段无效；且值设太高（如 20）易触发临时文件竞争，推荐 6–10
最常被忽略的一点：镜像源的稳定性不只看“是否在线”，而要看它是否在 TLS 证书轮换、CDN 节点故障、上游 Packagist 限流时仍能返回正确 HTTP 状态码。有些镜像在异常时返回 502 或空响应，会导致 Composer 重试逻辑紊乱——这种问题不会出现在测速报告里，但会在凌晨三点的 CI 构建中突然爆发。
