Composer报错Dependency resolution failed即存在循环依赖，必须用composer depends --tree定位闭环链路，再通过抽离契约包、运行时解耦或降级为可选依赖三种方式重构解决，不可跳过或强制安装。
Composer 报错 Dependency resolution failed 且提示循环依赖？先别删 vendor
这不是 Composer 坏了，而是你项目里真存在 A 包 require B 包、B 包又 require A 包的双向依赖。Composer 的解析器会直接拒绝这种结构——它不支持循环依赖，也不做拓扑排序降级处理。
怎么快速定位哪两个包在互相拉对方？
靠肉眼翻 composer.json 效率低，还容易漏掉间接依赖。用 composer depends 和 composer show 组合查最准：
- 运行
composer depends --tree vendor/package-a，看谁依赖了package-a - 再对结果里的某个包（比如
vendor/package-b）执行composer show vendor/package-b，重点看requires字段是否含vendor/package-a - 如果 A 依赖 B、B 又依赖 A，就坐实了死结；注意检查
require-dev里有没有偷偷加反向依赖（常见于测试工具包误写进主依赖）
为什么 composer update --with-dependencies 会让问题更难排查？
这个参数会强制升级所有子依赖，可能把原本“侥幸共存”的版本组合打散，暴露出底层循环。真实场景中，很多循环依赖靠版本号锁死才暂时没报错，一旦放开更新就会炸。
- 临时解决：加
--dry-run看计划更新列表，重点关注被标记为downgraded或upgraded的双向包 - 长期避坑：所有内部私有包之间禁止
require对方，改用接口抽象 + 依赖注入，或拆出第三个基础包放公共契约 - 特别注意：Laravel 的
orchestra/testbench在require-dev里常悄悄 require 主包，容易和主包形成循环
强行用 replace 或 conflict 能绕过吗？
不能。这两个字段只影响安装决策，不解决解析器的图遍历失败。你加了 "conflict": {"vendor/package-b": "*"}，Composer 依然会在解析阶段卡在 A→B→A 这条路径上，报错不会变。
- 唯一有效解法是打破依赖箭头：要么把 A 的某部分功能抽成新包 C，让 A 和 B 都依赖 C；要么把 B 中调用 A 的逻辑改成运行时反射或事件驱动，去掉静态 require
- 如果涉及历史包袱重的老项目，优先 grep 所有
use和new语句，确认 B 包里是否真需要 A 的具体类——很多时候只是误用了 A 的工具函数，其实可以 copy 出来或换其他通用包
循环依赖不是版本问题，是架构信号。哪怕暂时用 composer install --ignore-platform-reqs 蒙混过关，下次 CI 构建或换 PHP 版本时照样崩。
