Composer依赖解析卡死主因是镜像源未正确配对、缓存未清理及repositories配置冲突；需用composer config -g repo.packagist指定阿里云镜像并加/g参数，执行clear-cache和--refresh更新缓存，避免repositories字段覆盖全局镜像。
镜像源配对失败导致依赖解析卡死
Composer 卡在 Resolving dependencies 不是网络慢，而是元数据源没配对成功，本地还在用 packagist.org 的旧索引暴力回溯。必须用 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，漏掉 -g、写成 repos.packagist、URL 末尾少 / 或缺 composer 类型参数，都会静默失效。
验证是否生效：
- 运行
composer config -g repo.packagist，输出应为完整 URL 字符串 - 执行
composer show packagist/support，看source.url是否含mirrors.aliyun.com -
composer install -vvv日志末尾应出现Reading packages.json from cache at /https---mirrors-aliyun-com-composer/
缓存残留让镜像“形同虚设”
换镜像后仍拉 repo.packagist.org，90% 是缓存没清干净。Composer 优先读本地元数据缓存，哪怕镜像已配好，它仍用旧缓存里的地址去请求 provider 文件。
必须执行：
-
composer clear-cache—— 彻底重建缓存目录 - 若怀疑 provider 分片同步滞后（如 Laravel 11 相关包找不到），加
--refresh：composer update --refresh（≥2.5） - 别信
curl -I看 Last-Modified，那只是镜像站文件时间，不反映本地是否已更新缓存
repositories 数组让全局镜像彻底失效
只要 composer.json 里有 "repositories" 字段（哪怕空数组 "repositories": []），全局镜像配置就会被丢弃——不是合并，是直接忽略。
常见错误场景：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 项目加了私有源，又单独跑
composer config repo.packagist，结果私有包还是找不到 -
"repositories"里漏写"type": "composer"，Composer fallback 到 VCS 模式，跳过镜像代理 - 想禁用 packagist.org 却把
{"packagist.org": false}放在数组开头，导致查完私有源立刻退出
检查方式：composer config --list | grep repositories.packagist.url，输出为空即说明被覆盖。
镜像同步延迟引发“有新版却装不上”
现象是 composer update monolog/monolog 显示 Nothing to install or update，但镜像站页面已显示 v3.6.0。根本原因是本地复用了未过期的 packages.json 缓存，压根没发远程请求。
这不是 Composer bug，是设计使然：
- Packagist 元数据按命名空间切片（
provider-laravel~11.0.json等），镜像同步常滞后几小时 - 小众镜像若裁剪了
conflict或require-dev字段，会导致composer why-not判断失真 - 阿里云/腾讯云等主流镜像相对完整，优先选它们，别为“更快”换冷门源
真正卡点往往不在镜像本身，而在你没看清 composer why-not 输出里那条反向阻断链的最后一行——它永远是你 composer.json 里那句根声明，而不是镜像返回的某个 provider 文件。
