Composer卡在“Resolving dependencies”是本地SAT求解器暴力回溯版本冲突所致，非网络问题；镜像仅加速元数据下载，对Solver阶段无效，应通过composer why-not定位冲突、--no-dev缩小范围或调整模糊约束来解决。
composer require 卡住，90% 是没切对镜像，不是网络差 —— 切完阿里云或腾讯云镜像后，composer require 通常 1–3 秒完成。
为什么 composer require 会卡在 “Resolving dependencies…”
这不是下载慢，而是 Composer 在本地做依赖图求解（Solver 阶段），纯 CPU 运算，跟镜像无关。但如果你看到卡在 “Loading repository” 或 “Downloading packages.json”，那才是镜像没生效。
- 镜像只加速元数据（
packages.json）拉取，不加速 Solver -
composer require默认会触发全量依赖分析，尤其当composer.json里有"minimum-stability": "dev"或大量"dev-*"版本约束时，Solver 会扫描所有分支，耗时飙升 - 如果
composer.lock已存在且含旧元数据，require可能绕过镜像直接查本地 lock 文件，导致“看似没加速”
composer config -g repo.packagist 必须写对的三个硬伤点
配错就静默回退官方源，不报错、不提示，你根本不知道失败了。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
repo.packagist不能写成repos.packagist（多一个 s）、packagist（漏 repo. 前缀）或mirror（Composer 不识别） - 中间的
composer是 type 值，必须显式写出，不能省略或替换成https等字符串 - URL 必须是 HTTPS 且末尾带
/：例如https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会 404）
验证镜像是否真生效的三步法
别信感觉，用命令确认：
- 运行
composer config -g repo.packagist，输出必须是完整 JSON 对象：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null、报错或只返回 URL 字符串，说明没写进去 - 执行
composer require monolog/monolog -vvv 2>&1 | grep "Loading repository"，日志里应出现你配置的镜像域名，而非packagist.org - 若仍慢，检查
composer.json是否含"minimum-stability": "dev"或未锁定版本的dev-main，这些会让 Solver 放弃镜像缓存，直连 GitHub 分支
composer require 加速的边界在哪
镜像只管元数据下载，其他环节它不管：
- 不加速
Resolving dependencies…—— 这是 PHP 进程在本地穷举版本组合，和网络无关 - 不加速 ZIP 包解压（尤其 Windows + WSL 权限异常时卡在
Extracting archive…） - 不加速
post-autoload-dump或post-root-package-install脚本执行 - 不加速
vendor/autoload.php生成，这个步骤在require后自动触发，但属于文件 IO，非网络瓶颈
真正卡在 Resolving dependencies… 超过 10 秒，就得看 PHP 版本约束、dev 包数量、本地内存是否够用 —— 镜像再快也救不了 Solver。
