Composer 会拒绝安装存在循环依赖的包，检测到 A→B→A 类循环时立即中止并报错，不支持跳过检查；需用 composer depends --tree 定位路径，通过抽离共享逻辑、调整 require-dev 或拆分接口等方式手动打破循环。
Composer 会拒绝安装存在循环依赖的包
Composer 在 install 或 update 阶段执行依赖解析时，一旦检测到 A → B → A 这类直接或间接的循环引用，会立即中止并抛出明确错误。它不会尝试“解开”循环，也不支持配置跳过该检查。
常见错误信息形如：
Dependency resolution failed: Package a depends on b, which depends on a注意：这里的
a 和 b 是实际包名，可能嵌套多层（如 foo/bar → baz/qux → foo/bar）。
- 循环依赖在
composer.json的require字段中定义，Composer 解析的是声明关系，不是运行时调用 - 即使两个包在代码中没有互相调用，只要
composer.json中存在双向require，就会被判定为非法 - 使用
require-dev无法绕过该限制——开发依赖同样参与全局依赖图构建
如何定位循环依赖链
Composer 自带的 depends 命令能反向追踪依赖路径，是排查循环最直接的工具。假设你怀疑 vendor/a/package 被意外引入，可运行：
composer depends a/package --tree
输出会展示所有依赖 a/package 的上游包及其完整路径。若某条路径最终又回到起点（比如出现 a/package ← b/lib ← a/package），即确认循环。
- 务必在项目根目录执行，否则
depends只查当前composer.json声明，不反映真实安装图 -
--tree参数不可省略，否则只显示一级依赖，无法发现深层闭环 - 如果报错 “Package not found”，说明该包未被当前
composer.lock解析到——此时循环可能尚未触发，或已被 Composer 在早期阶段拦截
解决循环依赖必须修改包结构或依赖声明
没有“自动解环”机制，唯一可靠方式是打破至少一个 require 关系。常见做法有：
- 将共用逻辑抽离为独立的
shared-utils包，让a和b同时依赖它，而非彼此 - 把
b对a的依赖改为require-dev+autoload-dev，仅用于测试，不参与生产依赖图（前提是b运行时不真正需要a） - 使用
replace或provide声明虚拟包，替代硬依赖（适用于插件/扩展场景，例如"psr/log": "^3.0"被具体实现提供） - 若
a仅需b的接口定义，可将b的interface提取为单独的b-contracts包，a依赖契约，b实现契约
注意：minimum-stability、prefer-stable 或 conflict 字段都无法规避循环检测——它们影响版本选择，不改变依赖图拓扑。
自定义 Installer 或 Plugin 无法绕过循环检查
有人试图通过编写 Composer\Plugin 或重写 Installer 来干预依赖解析，但这是徒劳的。Composer 的循环检测发生在 Composer\DependencyResolver\Pool 和 Solver 层，属于核心解析器前置校验，早于任何插件钩子（如 PRE_INSTALL_CMD）执行时机。
试图 patch vendor/composer/semver 或替换 Solver 类不仅破坏升级兼容性，还会导致锁文件不一致、CI 失败等连锁问题。
真正棘手的地方在于：循环可能隐藏在第三方包的 composer.json 里，你无法直接修改。这时只能 fork 该包、修复其依赖声明、发布新版本，并在自己的 composer.json 中用 repositories 指向它——但要小心维护成本和上游同步风险。
