composer 依赖更新失败的根本原因是版本约束无解，需用 composer why-not 倒序分析冲突链；定点升级应使用 --with-dependencies；勿删 composer.lock，优先 dry-run 验证。
Composer 依赖更新失败，不是网络卡、配置错，也不是命令没输对——是当前 composer.json 里所有约束加起来，根本不存在一组版本能同时满足。它算不出解，就停住。
composer why-not 是唯一能穿透间接依赖的命令
报错末尾写着 Conclusion: don’t install guzzlehttp/guzzle:^7.5？这句没用，只是结论。真正要盯的是 composer why-not guzzlehttp/guzzle:^7.5 的输出，而且必须从最后一行倒着读。
- 最后一行通常是你的根项目（比如
myapp/myproject dev-main）在require字段锁死了guzzlehttp/guzzle的旧版 - 往上一行可能显示
laravel/framework v10.30.0 requires guzzlehttp/guzzle ^6.5，再上一行可能是phpunit/phpunit 10.5 requires guzzlehttp/guzzle ^7.2 - 如果某行末尾带
(conflict with foo/bar >=2.0)，说明那个包自己写了conflict字段，Composer 是照章执行，不是误判 - 输出为空或只有
nothing？那不是冲突，是guzzlehttp/guzzle:^7.5这个版本压根没发布过
composer update vendor/package --with-dependencies 才是定点升级
想升 monolog/monolog 到 v3，别写 composer update "monolog/monolog:^3"，也别只写 composer update monolog/monolog。前者带引号和 ^ 会让 Composer 去找“兼容的最新版”，后者默认不更新它的子依赖，大概率卡住。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 正确写法是：
composer update monolog/monolog --with-dependencies -
--with-dependencies的作用是：只重算monolog/monolog及其直接依赖，不碰phpunit、sebastian/exporter这类无关项 - 升级后立刻
git diff composer.lock：确认只有monolog/monolog和它直系依赖（比如psr/log）被改，多改一个symfony/polyfill-*都可能埋隐患 - 如果失败，说明它的某个子依赖本身也有冲突，此时再对那个子依赖跑一次
composer why-not
别删 composer.lock，先跑 composer install --dry-run
composer.lock 不是障碍，是你当前唯一已验证可行的依赖快照。删它等于扔掉线索，重来一遍只会更难定位。
- 拉新代码后报
Root requires X but Y is installed？大概率是别人提交了新composer.json却漏提composer.lock，此时应git checkout -- composer.lock恢复再试 - 本地环境不一致（PHP 版本、扩展不同）？直接
composer install就能过——它严格按 lock 文件安装 - 不确定升级会不会炸？先
composer install --dry-run或composer update --dry-run，它不改文件，但会明确告诉你哪些包会被动、是否触发主版本跳变、有没有新conflict冒出来
最常被忽略的点：^1.2.3 和 ~1.2.3 看似只是写法差异，实际决定版本范围是否有交集；conflict 字段是硬拦截，不会提前警告，只在解析阶段静默失败；require-dev 包全程参与求解，phpunit 拉进来的 sebastian/exporter 可能正在拖住你整个升级路径。
