Composer卡住本质是SAT求解器在爆炸式版本组合中暴力回溯失败，非递归深度问题；应优先用composer prohibits、why-not和depends --tree定位冲突包，再通过收紧约束、清理require-dev及配置国内镜像解决。
Composer 本身不执行“递归安装”，所谓“超大型依赖链”卡住，本质是 SAT 求解器在爆炸的版本组合空间里反复回溯失败——不是深度问题，是约束太松或图太乱。
为什么 composer update 会卡住十几分钟甚至失败
这不是 DFS 递归栈溢出，而是求解器在尝试所有满足约束的版本组合：一个包有 30 个可用版本，5 个强依赖就可能产生上千万种初始排列。每种都要验证 PHP 版本、conflict 字段、require-dev 约束、replace 声明……任一环节失败就回退重试。
- 加
minimum-stability: dev会让每个包的dev-main、dev-develop都进入候选集，搜索空间指数级膨胀 - 国内直连
packagist.org时网络延迟叠加元数据解析，Resolving dependencies through SAT行出现后常卡住不动 -
composer.json里写了"psr/log": "^1.0 || ^2.0 || ^3.0"这类宽泛约束，等于主动放弃剪枝机会 - 某个
require-dev包（如infection/infection）autoloads了你的src/，又反过来被你代码调用，形成隐式闭环，求解器会在 A→B→A 之间无限打转
快速定位瓶颈包的三个命令
别猜哪一层“递归”深，直接查谁在拖慢或阻断求解：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer prohibits vendor/package—— 查哪个包明确声明了conflict或通过require锁死了某个版本 - 运行
composer why-not vendor/package:3.0.0—— 输出会显示具体哪条依赖链拒绝了该版本，例如laravel/framework v10.32.1 requires monolog/monolog ^2.9 - 运行
composer depends --tree vendor/package—— 看是否出现vendor/a ← vendor/b ← vendor/a这种自指路径，这是循环依赖的铁证
真正有效的瘦身与加速手段
删包不是目的，切断无意义的传递依赖才是关键：
- 对纯测试工具（
phpunit/phpunit、mockery/mockery），加"prefer-stable": true和"minimum-stability": "stable"，避免拉dev-master搅乱主链 - 用
composer why-usage guzzlehttp/psr7查它被谁引入；如果只出现在require-dev的某条链里，且生产环境不用，就加--no-dev安装 - 删
autoload里无用条目："docs/": ["docs/"]、"tests/": ["tests/"]会让classmap白扫数百文件，拖慢dump-autoload - 国内用户必须配镜像：
composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/（注意旧 phpcomposer 镜像已停）
Monorepo 场景下的依赖链控制
本地 path 仓库不是“绕过依赖管理”，而是把子模块变成可解析的包节点。但极易因配置错位引发链式混乱：
-
repositories中url必须指向含合法composer.json的**具体目录**，写"services/*"只在 Composer 2.2+ 支持，且需每个子目录都有name - 子包
composer.json的name必须和根项目require中的完全一致，比如"acme/user-service"，少一个-都会导致 fallback 到远程源 - 根项目
require必须用"acme/user-service": "@dev"，写"^1.0"会让 Composer 忽略本地 path，去 Packagist 找匹配版本 - path 包安装后是符号链接，改子包代码立刻生效——但这也意味着子包的
autoload-dev若错误包含../src，就会把根项目代码反向加载进来，触发隐式循环
最常被忽略的点：所谓“依赖链长”，往往不是因为包多，而是因为 require-dev 和 autoload 的交叉污染让求解器无法收敛。先清掉非必要 dev 包，再看 --dry-run -v 输出末尾的 Conclusion 段，那里才写着真正的死锁位置。
