composer发现循环依赖会直接报错退出，确认方法包括：root package无法安装且卡在resolving dependencies、错误提示package a depends on b which depends on a、--dry-run -v回溯同一路径、depends --tree显示闭环链路。
Composer 不会“处理”循环依赖，它发现就直接退出——报错不是警告，是明确告诉你：这个依赖图逻辑上无解。
怎么一眼确认是循环依赖，不是版本冲突
看到这些现象，基本可以锁死是循环依赖：
-
Root package cannot be installed且卡在Resolving dependencies超过 30 秒（CPU 拉满、无网络请求） - 错误里反复出现类似
Package a depends on b, which depends on a的描述 - 运行
composer update --dry-run -v，末尾几行反复回溯同一路径，比如vendor/a → vendor/b → vendor/a -
composer depends myorg/core --tree输出中出现myorg/core ← myorg/api ← myorg/core（箭头方向是“被谁依赖”，自身出现两次即闭环）
用 composer depends --tree 定位真实闭环链路
这是唯一能看清间接环的命令，但有两个硬前提必须满足：
- 项目必须已成功执行过
composer install（保证composer.lock有完整快照） - 必须加
--tree参数，否则只显示一级依赖，根本看不到闭环 - 如果提示
Package not found，说明该包没进composer.lock——先composer clear-cache，再删vendor/和composer.lock，重跑composer update --dry-run看第一步失败点 - 重点查
require-dev引入的包：比如phpunit/phpunit的composer.json里写了"autoload": {"psr-4": {"App\": "../src/"}}，就把你的src/加进了它的加载路径；而你的代码又用了它的TestCase，运行时就形成隐式闭环
临时验证是否由 require-dev 引起
很多“循环”根本没写在 require 里，而是靠 autoload 悄悄打通的。最快速验证方式：
- 临时注释掉
composer.json中所有非核心的require-dev条目（如phpunit/phpunit、infection/infection、phpstan/phpstan） - 再运行
composer update --dry-run，如果不再卡住，问题就出在这里 - 逐个恢复
require-dev包，配合composer show package-name查它的autoload配置，特别留意含../、../../、src/的路径 - 检查你自己的
autoload-dev是否误把vendor/下的路径写进去了——这等于告诉 Composer：“我依赖我自己”
真正有效的破环方式只有三种
没有“跳过”“强制安装”或“忽略循环”的选项，只有结构重构：
- 抽离契约包：把双方共用的接口、DTO、异常类拎出来，建新包
myorg/contracts，然后myorg/core和myorg/api都只require "myorg/contracts": "^1.0"，删掉彼此的require - 运行时解耦：A 不再
new B()或use BSomeClass，而是定义interface ServiceInterface（放契约包里），B 实现它，A 通过容器或工厂获取实例——此时 A 的composer.json里彻底删掉对 B 的require - 降级为可选依赖：如果 B 只在 A 的测试里用（比如 Mock 数据），就移到
require-dev；如果是增强功能（如导出 Excel），改用suggest字段提示用户手动安装
最容易被忽略的是 autoload 和 require-dev 的越界引用——它们不会出现在 composer show -t 里，却能在运行时把依赖链悄悄焊死。
