Composer update太慢主因是镜像未生效：项目级repositories优先覆盖全局配置，需验证composer config -g repo.packagist输出是否为完整JSON，且必须执行composer clear-cache并确保URL末尾带/、含type值composer。
Composer update 太慢，基本就是镜像源没切对，或者切了但没生效。国内默认走 packagist.org 官方源，直连延迟高、带宽受限，尤其在 CI/CD 或新环境首次安装时卡在 Downloading 或 Resolving dependencies 阶段非常常见。
确认当前全局镜像源是否生效
很多人以为执行过 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就完事了，其实容易忽略几个关键点：
-
composer config -g修改的是全局配置，但项目根目录下若有composer.json里定义了repositories字段，会**优先覆盖全局设置** - 执行
composer config -g -l查看实际生效的全局配置，重点确认repo.packagist的值是否为你设置的镜像地址 - 某些公司内网或 Docker 环境可能被代理或 DNS 劫持，建议用
curl -I https://mirrors.aliyun.com/composer/packages.json直接测镜像站连通性与响应时间
推荐镜像源及对应命令（阿里云 / 清华 / 华为）
不是所有镜像都支持完整同步，也不是所有镜像都长期稳定。目前实测可用且更新及时的有三个：
- 阿里云（最稳）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 清华大学：
composer config -g repo.packagist composer https://packagist.phpcomposer.com（注意：该域名已停用，正确地址是https://mirrors.tuna.tsinghua.edu.cn/composer/） - 华为云：
composer config -g repo.packagist composer https://repo.huaweicloud.com/repository/php/
⚠️ 注意：https://packagist.phpcomposer.com 已不可用，很多旧教程还在写这个，直接执行会报 Could not fetch 错误；清华源必须用 tuna.tsinghua.edu.cn 域名，且路径结尾带斜杠
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
临时切换镜像（不改配置，适合 CI 或多项目场景）
有些项目需要隔离镜像源，或者你在调试时不想污染全局配置，可以用 -vvv + --repository-url 组合快速验证：
composer update -vvv --repository-url=https://mirrors.aliyun.com/composer/
这个命令会跳过所有本地配置，强制走指定镜像，并输出详细请求日志，方便判断卡在哪一步。如果这里快，说明问题出在你的配置没生效；如果依然慢，就要查网络或 DNS 了。
清除缓存并重试（常被忽略的一步）
镜像源改了，但 Composer 仍可能从旧缓存读取元数据，导致看似“切了源却没提速”：
- 运行
composer clear-cache清掉本地包缓存（含packages.json等元信息） - 删掉项目下的
vendor/和composer.lock（谨慎操作，仅用于调试） - 再执行
composer install或composer update，观察首屏是否出现Loading repositories with package information后快速进入依赖解析
真正卡住的地方往往不是下载包体本身，而是解析 packages.json 这个索引文件——它体积小但请求频次高，对 DNS 和 TLS 握手更敏感。镜像源是否支持 HTTP/2、是否部署 CDN，比单纯“有没有镜像”影响更大。
