Composer遇到循环依赖直接报错退出，是架构警告而非安装失败；必须用composer depends --tree定位闭环，再通过抽离契约包、运行时解耦或降级为可选依赖实现单向依赖。
Composer 遇到循环依赖不会“解决”，它直接报错退出——这不是安装失败，是架构警告。你看到的 Dependency resolution failed: Package a depends on b, which depends on a 不是配置没调好，而是依赖图里出现了逻辑闭环，必须从代码结构上打破。
用 composer depends --tree 定位真实闭环路径
别靠猜，也别只看报错里提到的两个包名。这个命令是唯一能实锤闭环的工具，但它有两个硬前提：
- 必须在已成功运行过
composer install的项目里执行，否则依赖图不完整 - 必须带
--tree参数，否则composer depends vendor/a只显示一级依赖，根本看不到环 - 如果提示
Package not found，说明该包连进composer.lock的机会都没有——先删掉vendor/和composer.lock，再跑composer update --dry-run -v看第一步卡在哪
实锤输出长这样：myorg/core ← myorg/api ← myorg/core。箭头方向是“被谁依赖”，同一包名出现两次就是闭环。
检查 require-dev 和 autoload 是否悄悄引入隐式循环
最多见的不是 require 互引，而是开发依赖通过自动加载“反向加载了你的代码”。比如你在 src/ 里用了 PHPUnit\Framework\TestCase，而 phpunit/phpunit 的 composer.json 里又写了 "autoload": {"psr-4": {"App\": "../src/"}}，Composer 就会把它当作生产依赖来解析。
- 临时注释掉
require-dev下所有非核心工具（如phpunit/phpunit、phpstan/phpstan），再试composer update - 检查所有
require-dev包的composer.json，搜"../src"、"../../myproject/src"这类路径 - 确认你的
autoload-dev没把vendor/下的路径写进去——这等于告诉 Composer：“我依赖我自己”
真正有效的破环方式只有三种，没有“跳过”选项
所有靠谱方案都指向一个目标：让依赖方向变成单向。任何 --ignore-platform-reqs 或手动改 vendor/ 都只是掩盖问题，下次更新照样崩。
-
抽离契约包：把共用的接口、DTO、异常类拎出来建新包（如
myorg/contracts），它的composer.json中"require": {}应为空；myorg/core和myorg/api都只require "myorg/contracts": "^1.0" -
运行时解耦：A 不再
new B()或use BClass，而是定义LoggerInterface（放契约包），B 实现它，A 通过容器获取实例；此时 A 的composer.json里必须删掉对 B 的require -
降级为可选依赖：如果 B 只在 A 的测试中用，移到
require-dev；如果是增强功能（如导出 Excel），改用suggest字段提示用户手动安装
最容易被忽略的是私有包元数据缓存和 monorepo 下的 path 源顺序问题——清理 composer clear-cache 后，还要确认 Satis/Toran 生成的 dist 包信息没把 require-dev 也塞进去；用 {"type": "path", "url": "../packages/*"} 时，packages/a 和 packages/b 的相互引用会因路径通配被优先加载，形成本地可装、CI 上必崩的隐式环。
