Composer版本冲突本质是依赖约束无交集，需通过composer why-not、show --tree等命令定位封杀源，再精准调整版本或拆分项目解决。
Composer 版本冲突不是“装不上”，而是“找不到所有包都同意的版本”——它已经穷举过所有组合，发现没有交集，所以直接放弃。
看懂报错里真正卡住的是谁
报错末尾通常会写 Your requirements could not be resolved，但关键信息藏在前面或加 -v 后的「Conclusion」段。比如：
Root requires monolog/monolog ^2.0, but package-x v3.1.0 requires monolog/monolog ^1.25 → satisfiable by monolog/monolog[1.25.0]
这说明不是 monolog 本身有问题，而是 package-x 把它死锁在了 1.25.0。
- 别急着删
vendor或composer.lock——那是掩盖问题，不是解决 - 先跑
composer why-not monolog/monolog:2.9.0，看哪几个包在联合封杀这个版本 - 再跑
composer show --tree | grep monolog，确认它是不是被require-dev里的某个测试工具悄悄拉进来的 - 注意
composer prohibits和composer depends的区别：prohibits告诉你“谁不让装”，depends告诉你“谁在用它”
改 composer.json 不是乱调，而是找交集区间
冲突本质是多个约束没重叠，比如一个要 ^1.25，另一个要 ^2.10。它们之间没有语义化版本交集，Composer 就没法选。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 去 Packagist 查这个包哪些版本同时出现在不同依赖的
require列表里（比如v2.9.3可能被 A 包的^2.0和 B 包的>=2.8.0同时接受） - 把
"monolog/monolog": "^2.0"改成"monolog/monolog": "2.9.3"，然后只跑composer update monolog/monolog，避免牵连其他包 - 如果必须兼容两个大版本，可写
"monolog/monolog": "^1.25 || ^2.10"，但前提是你的代码真能同时跑通两套 API —— 不然只是把问题拖到运行时报错 - 别在
require-dev里塞和主项目冲突的包，比如主项目用laravel/framework: ^10.0，就别让orchestra/testbench: ^7.0进来，它内部硬绑 Laravel 9
重建依赖树时，别全量更新，要分批验证
composer update 卡在 Resolving dependencies 超过 5 分钟？那不是网络慢，是 SAT 求解器在暴力试错，尤其当项目有 conflict、replace 或 30+ 包时，复杂度指数上升。
- 先跑
composer update --dry-run -v，看日志里反复出现Trying+ 回退，确认是解析瓶颈 - 用
composer update vendorA/pkgA vendorB/pkgB --with-dependencies，缩小搜索空间，每次只动一两个关键路径 - 临时移除
composer.json里的"conflict"字段（仅用于诊断），或把"minimum-stability"改成"RC"看能否快速出解——但改完立刻还原，不能留着上线 - 删
composer.lock和vendor后跑composer install是“重开一局”，适合接手老项目；但若团队协作，必须提交新lock文件，否则别人install会失败
有些“冲突”其实是误报，但绕过前得确认它真不咬人
比如两个包都声明兼容 symfony/console 6.x，但一个写 ^6.0，另一个写 ^6.2，理论上没问题，Composer 却因解析策略报错。
-
composer update --with-all-dependencies有时比默认行为更干净，但它会升级整棵树，可能把guzzlehttp/guzzle从 7.x 推到 8.x，导致new GuzzleHttp\Client()报错 -
--ignore-platform-reqs只跳 PHP 版本或扩展检查，对逻辑冲突无效；--no-scripts --no-plugins可防脚本触发额外依赖，适合调试 -
"replace": { "conflicting/package": "*" }是危险操作：它告诉 Composer “这个包不存在，别管它”，但如果运行时真需要，就会直接崩 - 最稳妥的隔离方式，是把冲突组件抽成独立子项目，用 HTTP 或 CLI 调用，而不是硬塞进同一张依赖图里
真正难的从来不是命令怎么敲，而是判断哪个包该升、哪个该锁、哪个其实根本不用——这得看 composer show --tree 里每一层是谁引的，以及你敢不敢删掉那个写了三年没人维护的 dev 工具。
