“Root package requires but it is not installable”是循环依赖或版本约束冲突的典型表现，源于composer.json中require规则与现有依赖图无法共存，需优先运行composer why-not定位具体阻断包及互斥约束链。

“Root package requires but it is not installable”不是网络问题或权限问题，而是 Composer 明确告诉你：你写的 composer.json 里某条 require 规则，和当前已解析的依赖图完全无法共存——没有一个版本能同时满足所有约束。

为什么 composer why-not 是第一个该跑的命令

报错里只写 monolog/monolog ^2.0 不可安装，但没说谁在拦。这时候别翻 composer.json 猜，直接问：

• composer why-not monolog/monolog:^2.0 会输出具体哪几个包在提互斥要求，比如：
  myapp/core dev-main requires monolog/monolog ^1.26
vendor/sdk v3.2 requires monolog/monolog ^2.0
• 如果返回空，说明冲突来自 conflict 字段、require-dev 或平台约束（如 PHP 版本），得补查 composer show --tree 和 composer diagnose
• 注意：它查的是“被拒绝的版本”，不是你当前装的版本——别用 composer why monolog/monolog 替代，那个只查已安装版本的依赖源

改 composer.json 前先确认谁真能动

不是所有包都能随便降级或升级。关键看控制权和 SemVer 兼容性：

Workflow Decomposer

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

下载

• 如果你维护 acme/payment-sdk，优先改它的 composer.json：
  把 "monolog/monolog": "1.26.1" 改成 "monolog/monolog": "^1.26 || ^2.0"，再 composer update acme/payment-sdk
• 如果冲突来自已归档的 aws/aws-sdk-php:2.x，别硬升——它和 guzzlehttp/guzzle:^7 天然不兼容，换 async-aws/core 更省事
• 根项目里写了 "php": "8.1"，但某个新包要求 "php": "^8.2"，这时要么升 PHP，要么找旧版包——composer show vendor/package 看它是否还维护 8.1 兼容的 2.x 分支

composer update 加参数反而让问题更难解

--with-all-dependencies 不是“跳过冲突”，而是强制重算整棵树，可能把原本稳定的 symfony/console 从 v5 升到 v6，结果运行时报 Class Command not found：

• 想只动一个包？用 composer update vendor/package-name（不带版本号）
• 必须全量更新？先 composer update --dry-run，重点盯输出里有没有 downgrading 或 removing 关键包
• 怀疑 composer.lock 过期导致误判？别直接删，先 git checkout -- composer.lock 回退再试，避免破坏团队环境一致性

真正卡住的地方往往不在报错第一行，而在某个 require-dev 里的 phpunit/phpunit 悄悄锁死了 sebastian/exporter:3.1，而新包需要 4.0+。这种隐性依赖链，不用 composer why-not 和 composer show --tree 交叉验证，很容易反复试错半天。