Composer install 遇到循环依赖会失败，因其将循环视为配置错误而非需智能解决的问题，基于SAT求解但默认禁用回溯式解环，检测到A→B→A即终止并报错。
Composer 会直接报错退出，不尝试自动解环或降级。它把循环依赖视为配置错误，而非需要智能解决的问题。
为什么 composer install 遇到循环依赖会失败？
Composer 的依赖解析器基于 SAT 求解（布尔可满足性），但默认禁用回溯式解环。一旦检测到 A → B → A 这类路径，它就终止并抛出清晰错误，而不是尝试版本回退、跳过约束或拆包重排。
- 错误信息形如：
Root composer.json requires package-a ^1.0, but package-b v2.1.0 requires package-a ^0.9, and package-a v0.9.5 requires package-b ^2.0 — cyclic dependency detected. - 这不是性能问题，是设计选择：强制开发者显式打破循环，避免隐式行为导致后续更新不可控
- PHP 扩展包（如
ext-redis）本身不参与 Composer 依赖图，但其对应的包装器包（如phpredis/phpredis）会——循环通常出现在这类纯 PHP 包之间
如何定位循环链中的具体包和版本？
靠肉眼读 composer.json 很难发现跨多层的依赖环。要用 composer depends 和 composer show 逐层追查。
- 先运行
composer depends --tree <package-name>查看谁依赖了目标包及其传递路径 - 再对可疑包执行
composer show <package-name> --tree，观察它又反向依赖了谁 - 特别注意
require-dev中的包——它们可能在测试时引入反向依赖，但生产环境不需要 - 使用
composer why-not <package>:<version>可快速验证某个版本是否被某条路径阻断
打破循环的三种实际可行方式
没有“最优解”，只有适配项目上下文的选择。关键不是绕过检查，而是让依赖关系真正线性化。
立即学习“PHP免费学习笔记（深入）”；
- 将共享逻辑抽成独立新包（如
myorg/shared-utils），让 A 和 B 同时依赖它，而非互相依赖 - 用接口抽象 + 运行时注入替代硬依赖：A 声明
interface CacheDriver，B 实现它，A 通过容器获取实例，不 require B - 移除
require-dev中的非必要包；若必须保留，改用autoload-dev加条件加载，避免进入主依赖图
最常被忽略的是 replace 和 provide 字段的误用——它们可能在未察觉时伪造了兼容性声明，导致求解器误判路径。只要看到循环报错里出现 provides 相关描述，优先检查这些字段是否准确反映真实能力。
