composer 遇到循环依赖直接报错中止，因依赖图存在闭环，需通过抽离契约、运行时解耦或降级为可选依赖实现单向依赖。
Composer 一见到循环依赖就直接报错中止
它不尝试解开，也不让你跳过——Dependency resolution failed: Package a depends on b, which depends on a 这类错误出现，说明依赖图里出现了闭环，Composer 立刻退出。这不是配置问题，也不是版本没选对，而是架构层面的信号：两个包不该互相“require”对方。
常见错误现象包括：
- 执行
composer update卡在解析阶段，报错但不提示具体哪一行 -
composer install失败，提示某包“无法满足其自身依赖” - 本地开发时能装上，CI 上失败——往往是因为缓存了旧版
composer.json元数据
用 composer depends --tree 定位谁在拉谁
别猜，直接看依赖路径。比如你怀疑 myorg/core 被循环引入，就在项目根目录运行：
composer depends myorg/core --tree
输出里如果出现 myorg/core ← myorg/api ← myorg/core，就是实锤。注意两点：
-
--tree必须加，否则只显示一级依赖，看不到闭环 - 命令必须在已
composer install过的项目里运行，否则依赖图不完整 - 若报
Package not found，说明该包没进 lock 文件——可能已被早期拦截，或根本没被声明
真正有效的破环方式只有三种
没有“绕过”，只有“重构”。所有靠谱方案都指向一个目标：让依赖方向变成单向。
- 抽离公共契约：把双方共用的接口、DTO、异常类拎出来，建个新包
myorg/contracts，"require": {}保持干净；myorg/core和myorg/api都只require "myorg/contracts": "^1.0" - 运行时解耦：A 不再
new B()或use BSomeClass，而是定义interface LoggerInterface（放在契约包），B 实现它；A 通过容器或工厂获取实例——此时 A 的composer.json里彻底删掉对 B 的require - 降级为可选依赖：如果 B 只在 A 的测试里用（比如 Mock 数据），就移到
require-dev；如果是增强功能（如导出 Excel），改用suggest字段提示用户手动安装
容易被忽略的坑：autoload 和 require-dev 的越界引用
你以为只是开发依赖，结果它悄悄污染了主依赖图。
- 检查
autoload配置：如果"psr-4": {"App\": "src/"}，而src/里用了require-dev包的类（比如phpunit/phpunit），Composer 就会把它当作生产依赖来解析 - 确认
autoload-dev是否只覆盖tests/或stubs/，且没和autoload的命名空间重叠 - 私有仓库更新后，记得
composer clear-cache，否则 Composer 仍拉取旧版元数据，改了也白改
最麻烦的情况是：循环不在你写的包里，而在你引用的第三方包之间。这时只能联系维护者，或者 fork 后临时 patch —— 但得先确认是不是真没法绕开，比如用 replace 声明自己已提供某接口。
