镜像配置需满足三要素：repo.packagist（单数）、末尾带composer类型标识、url以斜杠结尾；生效后应输出完整json；还需清除缓存并检查项目级repositories覆盖问题。
镜像配置写对了但根本没生效
很多人执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就以为搞定了，结果 composer install 日志里还是在请求 repo.packagist.org。这不是网络问题，是配置静默失败——三个硬伤缺一不可：
-
repo.packagist必须是单数形式；写成repos.packagist或repositories，Composer 完全忽略，不报错也不提示 - 命令末尾必须显式带上
composer类型标识；漏掉它，会 fallback 到默认源https://packagist.org - URL 必须以斜杠结尾：
https://mirrors.aliyun.com/composer/✅；少一个/就返回 404，路径拼接直接出错
验证是否真生效：运行 composer config -g repo.packagist，输出必须是完整 JSON，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null、或含 packagist.org，说明压根没写进去。
缓存没清，旧元数据还在拖后腿
换源后不执行 composer clear-cache，Composer 会优先读取本地缓存里的 packages.json 和元数据——这些内容仍指向旧地址，导致 DNS 解析、TLS 握手卡十几秒不动，哪怕配置已改也白搭。
更隐蔽的问题是项目级 composer.json 里存在 "repositories" 字段（哪怕只是空数组），会直接覆盖全局镜像配置。检查方法：
- 运行
composer config --list --global和composer config --list对比，确认实际生效的是哪个 - 临时绕过所有自定义源测试：
composer install --no-plugins --repository=https://packagist.org，如果变快，说明本地配置冲突
并发下载开了但根本没跑起来
parallel-downloads=10 不是万能加速键。它只在 Composer 2.2+ 生效，且严重依赖镜像源支持 HTTP/2 多路复用。阿里云镜像目前最稳，腾讯云/华为云偶尔同步延迟或 CDN 节点异常，会导致并发请求排队堵死。
并发过高还会触发临时文件竞争，典型报错：file_put_contents(/tmp/): failed to open stream。此时应立刻降到 6 或 8。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
另外注意：parallel-downloads 只对 composer install 有效，对 composer update 几乎无加速作用——因为依赖求解（SAT）本身是串行的。
卡在 Resolving dependencies 不是网络问题
这个阶段完全不走网络，是 Composer 在本地穷举满足所有约束的版本组合。尤其当你写了 "*"、"^1.0 || ^2.0" 或 "minimum-stability": "dev" 时，求解器会指数级爆炸。
更麻烦的是，镜像元数据同步有 5–30 分钟延迟。如果 composer.lock 里记录的是刚发布的包版本，而镜像还没同步，Solver 就会反复尝试已下线的版本号，陷入死循环。
实操建议：
- 删掉
composer.lock（仅限开发环境），再跑composer update --with-all-dependencies - 加
-v参数看具体卡在哪条包的versions请求，然后手动curl https://mirrors.aliyun.com/composer/p2/vendor/package.json测试该包是否存在 - 设
"minimum-stability": "stable"，避免自动拉取dev-或alpha分支触发额外校验
真正卡住的地方，往往不在下载链路，而在你没意识到的本地约束和元数据滞后上。
