Composer安装依赖冲突解决_Composer版本库不匹配修复技巧【实战】-composer-PHP中文网

Composer 报错“Your requirements could not be resolved”本质是依赖约束无解，需从composer why-not输出的最后一行（根项目）倒推约束链，结合PHP版本、conflict字段、replace规则及require-dev干扰等综合排查。

composer安装依赖冲突解决_composer版本库不匹配修复技巧【实战】

Composer 报 “Your requirements could not be resolved” 不是网络或权限问题，而是当前所有已声明约束（包括 require、require-dev、lock 文件快照、PHP 平台配置）之间找不到一个共同满足的版本组合——它已经穷举过，没解。

composer why-not 显示一堆路径，怎么读才对

输出里每一行末尾的 (required by xxx) 是向上追溯的起点，必须从最后一行开始倒着看：最后一行是你自己的 composer.json，往上才是层层传递下来的约束链。比如：

monolog/monolog 2.10.0 requires php >=8.0
laravel/framework v10.35.0 requires monolog/monolog ^2.9
myapp/core v3.2 requires laravel/framework ^10.0
your-project requires myapp/core ^3.2

这说明你根项目要 myapp/core ^3.2，但它拉来了 L10，L10 要 monolog ^2.9，而 monolog 2.10.0 又强制要求 PHP 8.0+ —— 如果你本地是 PHP 7.4，冲突就在这儿卡死。

别指望 why-not 直接告诉你“该删哪个包”，它只反映当前锁文件/已装状态下的约束快照
如果某行末尾是 conflict with vendor/pkg (>=2.0)，说明那个包自己写了 conflict 字段，不是 Composer 主动拦你
运行前先确认 PHP 版本：php -v，再查 composer show vendor/pkg 看它实际装的是什么版本、require 列表长什么样

composer update 卡住或报 “don’t install X” 怎么办

这不是命令失败，是 Composer 明确拒绝：它算过所有可能组合，发现无解。盲目删 vendor/ 或 composer.lock 只会让下次 install 更难复现问题。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

先跑 composer update --dry-run 预演，看它打算动哪些包；加 -v 能看到具体哪条约束堵住了
想升某个包但被子依赖锁死？用 composer update vendor/package --with-dependencies，否则默认不更新它的依赖，大概率失败
不要写 composer update "vendor/package:^3" —— 引号 + ^ 会让 Composer 去找兼容的最新版，而不是你心里想的那个“3.x 的某个确定版本”
升级后立刻 git diff composer.lock，确保只有目标包及其直系依赖被改，没波及其他稳定模块

require-dev 悄悄拖垮生产环境依赖

require-dev 默认全程参与依赖解析，哪怕你部署时加了 --no-dev。比如 phpunit/phpunit 和主框架都依赖 sebastian/exporter，但 PHPUnit 锁死了 ^4.0，而框架要 ^5.0，Composer 就会直接放弃。

CI/CD 中务必用 composer install --no-dev --optimize-autoloader，避免测试工具干扰主流程
若某个 dev 包反复引发冲突，考虑用 config.platform 虚拟锚定它，例如：
{"config": {"platform": {"phpunit/phpunit": "9.6.13"}} —— 它不真装，只提供版本参考
检查 composer show -t 输出，重点看同名包是否在不同路径下被引用多个版本（如 symfony/console 出现在 Laravel 和 PhpUnit 两条线里），这是隐性冲突前兆

最常被忽略的一点：冲突未必来自你写的代码，而可能来自某个你没注意的 replace 或 conflict 字段——它们全局生效，哪怕你根本没 require 那个包，只要其他依赖间接拉进来了，就会触发。查 composer show vendor/package 的输出，翻到底部看 replaces 和 conflicts 字段，比猜更可靠。