Composer 安装失败报“Root package requires... not installable”通常是循环依赖触发解析器保护机制，如A→B→C→A闭环或root包自依赖，需检查require、replace/provide配置并用depends/show命令定位路径，优先用provide声明实现而非删除依赖。
Composer 安装失败报 Root package requires ... which is not installable，大概率是循环依赖触发了依赖解析器的保护机制
Composer 本身不支持真正的循环依赖：比如 A → B → C → A 这种闭环，解析器会在构建依赖图时直接拒绝，而不是进入死循环。它不会“尝试解决”，而是提前终止并报错。常见现象是某个包声明了对当前项目（root package）的依赖，或通过 replace/provide 规则间接形成闭环。
- 检查
composer.json中是否误写了"my-vendor/my-project": "dev-main"这类指向自身的 require - 运行
composer depends --tree查看谁在拉取你本想安装的包（可能上游包已replace了它） - 用
composer show -t输出完整依赖树，人工扫描是否有返回到 root 的路径
使用 replace 和 provide 打破虚假循环
很多所谓“循环依赖”其实是语义冲突：两个包都声称自己“提供”同一个虚拟功能（如 psr/log-implementation），而第三方包同时 require 了二者，导致 Composer 认为它们互斥。这时不是删依赖，而是明确告诉 Composer：“我这个包已经实现了它，不需要再装另一个”。
{
"name": "acme/logger",
"require": {
"psr/log": "^2.0"
},
"provide": {
"psr/log-implementation": "2.0.0"
}
}
注意：provide 不会自动安装被提供的包，只用于满足其他包的 require；replace 则会完全屏蔽被替换的包（慎用，尤其别 replace php 或核心组件）。
composer update --with-dependencies 和 --no-update 的真实作用
面对复杂依赖冲突，盲目 composer update 往往让问题更糟——它会尝试升级所有包以寻找新解，但可能引入更多不兼容变更。真正可控的做法是分步锁定：
- 先用
composer install --no-interaction --no-scripts跳过脚本和交互，快速验证基础依赖能否落地 - 若失败，加
-v看详细解析日志，重点找will not be installed后面的包名 - 对关键冲突包，用
composer require vendor/package:1.2.3 --no-update先写入composer.json，再手动运行composer update vendor/package --with-dependencies局部更新
私有包 + path repository 导致的隐式循环
本地开发时习惯用 "type": "path" 引入兄弟包，但如果 A 的 composer.json require B，B 又 require A（哪怕只是 dev-require），Composer 会因路径解析顺序问题报错，即使物理上没循环。
解决方法不是改路径，而是拆离共享逻辑到第三个包，或改用 satis/toran 托管私有包并走标准 HTTP 源——路径仓库绕过了版本约束校验，容易掩盖真实依赖关系。
真要保留 path 方式，确保所有 path 包的 version 字段显式设为 dev-main 或固定版本号，避免 Composer 把 dev-main 当作“最新快照”反复重解析。
