根本原因是 Composer 默认依赖求解器采用暴力回溯算法，复杂约束下计算复杂度指数级上升；换国内镜像仅加速下载，无法改善解析；启用 SAT 求解器镜像（如 packagist.jp）或精简约束才能真正解决。
为什么 Composer install 会卡在 “Resolving dependencies”？
根本原因不是网络慢，而是 PHP 的 composer/composer 默认用纯 PHP 实现的依赖求解器——它把依赖图当作树暴力回溯，遇到复杂约束（比如多个包要求不同版本的 monolog/monolog、或带 conflict 规则的包）时，计算复杂度指数级上升。
这不是镜像能解决的问题；换国内镜像（如阿里云、腾讯云）只加速包下载，对解析阶段毫无帮助。
真正起作用的是支持 SAT 求解器的镜像服务
少数镜像（如 https://packagist.jp 或自建 toran-proxy）后端集成了基于布尔可满足性（SAT）的图计算引擎，把依赖关系建模为逻辑表达式，用工业级求解器（如 minisat）快速判定是否存在可行解。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须确认镜像文档明确写有 “SAT solver”、“dependency graph solver” 或 “faster resolver” 等关键词，光说 “高速同步” 没用
- 切换方式不是改
composer.json，而是改全局配置：composer config -g repos.packagist.org.url https://packagist.jp
- 部分镜像要求认证 token（如
packagist.jp需注册并填入COMPOSER_AUTH环境变量）
本地启用 --prefer-dist 和 --no-suggest 能否提速？
不能缩短解析时间，但能减少后续耗时，避免干扰判断：
-
--prefer-dist让 Composer 下载压缩包而非 git clone，对解析阶段无影响，但能显著缩短安装总时长（尤其含大量 dev 依赖时） -
--no-suggest只跳过提示信息输出，不参与依赖计算 - 真正影响解析的开关是
--dry-run（只解析不安装）和--verbose（显示解析过程），可用于定位卡点
什么时候该放弃镜像，直接改约束？
如果换了 SAT 镜像仍卡住超过 2 分钟，大概率是 composer.json 写法触发了组合爆炸：
- 避免同时 require 多个大生态包（如
laravel/framework+symfony/symfony+drupal/core），它们对php、ext-json等底层依赖的约束常冲突 - 检查是否有宽泛版本约束，比如
"^1.0 || ^2.0"比"^2.3"更难求解 -
conflict和replace规则越多，SAT 求解器负担越重；非必要不写
解析慢的本质是约束太强或太模糊，镜像只是让机器跑得更快一点——但跑得再快，也解不开逻辑上无解的问题。
