Composer碰上循环依赖，二话不说直接报错退出，不给你任何跳过或忽略的选项。这其实不是配置问题，而是依赖图里出现了A→B→A这样的逻辑闭环，必须从结构上打破。
怎么确认是循环依赖，不是版本冲突
报错信息里反复出现两个包互相拉取，比如“Package a depends on b, which depends on a”，基本就是实锤。但更常见的是伪装成“无法安装root package”或卡在“Resolving dependencies”超过30秒——SAT求解器正在死循环里打转，不是网络慢。
- 运行
composer update --dry-run -v，看最后几行是否反复回溯同一组包（比如vendor/a → vendor/b → vendor/a） - 执行
composer depends --tree vendor/a，输出中若出现vendor/a ← vendor/b ← vendor/a，箭头方向是“被谁依赖”，自身出现两次即闭环 - 如果报
Package not found，说明该包根本没进composer.lock，可能被早期拦截了——先删掉vendor/和composer.lock，再跑composer update --dry-run观察第一步失败点
用composer depends --tree定位真实闭环路径
这个命令是唯一靠谱的诊断入口，但它有硬性前提：必须在已成功composer install的项目里运行，否则依赖图不完整；且必须加--tree参数，否则只显示一级依赖，看不到闭环。
- 查可疑包：例如怀疑
myorg/core被循环引入，运行composer depends myorg/core --tree - 实锤闭环的输出长这样：
myorg/core ← myorg/api ← myorg/core - 临时注释掉
require-dev下所有非核心工具（比如phpunit/phpunit、phpstan/phpstan），再试一次composer update——很多“循环”其实是测试工具反向加载了你的src/
真正有效的破环方式只有三种
没有绕过，只有重构。所有靠谱方案都指向一个目标：让依赖方向变成单向。
- 抽离公共契约：把共用的接口、DTO、异常类拎出来建新包（如
myorg/contracts），它的composer.json中"require": {}应为空；core和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字段提示用户手动安装
最容易被忽略的隐式循环：autoload + require-dev 组合陷阱
你以为只是开发依赖，结果它悄悄污染了主依赖图。检查所有require-dev包的composer.json，重点看它们的autoload字段是否包含你项目的目录（如"../src"或"../../myproject/src"）。
- 确认
autoload-dev是否只覆盖tests/或stubs/，且没和autoload的命名空间重叠 - 如果
"psr-4": {"App\": "src/"}，而src/里用了phpunit/phpunit的类，Composer就会把它当作生产依赖来解析 - 私有仓库更新后，记得
composer clear-cache，否则仍拉取旧版元数据，改了也白改
真正难处理的不是显式require互引，而是autoload路径越界、require-dev包反向加载src、或者path类型仓库在monorepo里隐式闭环——这些不会在composer.json里写明，却能让composer update在毫无征兆的情况下卡死。
