Composer 报“Root package cannot be installed”大概率是存在循环依赖，如 A → B → A，其不支持解环而直接报错；常见诱因包括开发依赖、replace规则、分支别名或path仓库隐式闭环，需用composer depends定位并移除require-dev验证。
Composer 报 Root package cannot be installed 时大概率是循环依赖
Composer 本身不支持循环依赖，遇到 cycle detected 或安装失败但提示包版本冲突、root package 无法安装，基本可以断定是 A → B → A 这类隐式或显式环路。它不会尝试解环，而是直接报错退出。
常见诱因不是你手动写了 "vendor/a": "dev-main" 在 vendor/b 的 composer.json 里，而是通过开发依赖、replace 规则、分支别名（如 "dev-main as 1.0.x-dev"）或私有包镜像同步延迟，间接形成闭环。
- 检查所有参与包的
require和require-dev，特别留意测试工具包（如phpunit/phpunit）是否被某个业务包反向require-dev了 - 运行
composer depends --tree <package-name></package-name>查依赖链，再对可疑包反查：composer depends --tree vendor/a - 临时删掉
require-dev再composer update，看是否恢复——这是最快速的定位手段
用 replace 和 provide 拆分共享逻辑时的典型陷阱
想把公共接口抽成 vendor/interfaces，又让 vendor/core 和 vendor/app 都 require 它，结果 core 里不小心加了一行 "vendor/app": "self.version" —— 环就闭上了。
replace 不等于“我替代它”，而是“当我装上，Composer 就当那个包不存在”。如果 app 声明 "replace": {"vendor/core": "*"}，而 core 又 require app，Composer 会认为两者互斥，无法共存。
-
provide更安全，只声明能力（如"psr/log-implementation": "1.0"），不干涉包存在性 - 禁止在稳定分支中使用
"dev-main as 1.0.x-dev"这类别名指向自身主干——其他包依赖你时，可能解析出不可预测的版本约束 - 私有包若用 Satis / Toran，确保其元数据生成脚本不把
require-dev也塞进 dist 包信息里
单仓库多包（monorepo）下 path 仓库引发的隐式循环
用 {"type": "path", "url": "../packages/*"} 加载本地包时，很容易忽略路径通配的实际加载顺序。比如 packages/a require packages/b，而 packages/b 的 composer.json 里又写了 "require": {"myorg/a": "dev-main"} —— Composer 会优先走 path 源，于是 a ← b ← a 成立。
这种环在 CI 上可能不暴露，因为本地 path 源被缓存或路径解析顺序偶然正确；但换一台机器或清理 vendor 后立刻崩。
- 所有
path类型仓库必须确保：被依赖方不反向 require 同一 monorepo 下的其他包（除非用symfony/flex那种插件机制隔离） - 改用
composer config repositories.xxx.type composer+ 私有 Packagist，把开发态和发布态彻底分开 - 在
packages/b/composer.json中，把对myorg/a的依赖改成"myorg/a": "dev-main as 0.1.0"并确保a的version字段明确设为"0.1.0"，切断解析歧义
为什么不能靠 minimum-stability 或 prefer-stable 绕过
这两个配置管的是版本选择策略，不是依赖图拓扑校验。就算你把 minimum-stability 设成 dev，Composer 依然会在解析阶段检测到 A → B → A 并直接拒绝，连版本比较都不会触发。
有人试过在 require 里写 "vendor/a": "9999999-dev" 强制跳过约束，结果只是把错误从“循环”变成“找不到匹配版本”，本质没变。
- 真正有效的干预点只有两个：砍掉某条
require，或把其中一环改为运行时加载（如用 PSR-4 自动加载 + 接口约定，而非硬依赖） - 如果必须双向交互，用事件总线（
symfony/event-dispatcher）或消息队列解耦，而不是 Composer 依赖 - 所有试图用别名、稳定性标签、分支别名“欺骗” Composer 解析器的行为，最终都会在更新、安装、lock 文件生成任一环节露馅
循环依赖不是版本问题，是架构信号。Composer 只负责报错，不负责救火。拆分边界时，多看一眼 composer depends 输出的树，比调半天 config 有用得多。
