Composer不支持循环依赖，报错即明确拒绝；95%的“循环感”实为间接版本死锁，需用composer why-not定位拦截链，或composer depends反查源头，dev分支易引发隐性冲突。
Composer 本身不支持真正的循环依赖，报错就是明确拒绝——这不是配置问题，是语义冲突。 它会直接在 composer install 或 composer update 阶段抛出 Your requirements could not be resolved，并附上 SAT 求解器判定无解的路径。所谓“循环依赖”，95% 是间接依赖链形成的版本死锁，不是 A → B → A 这种显式环。
为什么 composer show --tree 看不出循环，却总报冲突？
Composer 的依赖图是 DAG（有向无环图），它不允许构造出数学意义上的循环。你看到的“循环感”，其实是多个包对同一底层包提出互斥版本要求，比如：
-
package-a要求symfony/event-dispatcher:^6.0 -
package-b要求symfony/event-dispatcher:^5.4 - 而你的项目又锁定了 PHP 8.2 —— 这时
symfony/event-dispatcherv5.4 不满足 PHP 8.2 的最低要求，v6.0 又被package-b的约束排除
这种情况下，composer show --tree 显示的是线性展开的依赖树，但冲突根源藏在“谁拉低了 symfony/event-dispatcher 版本”里。此时必须用 composer depends symfony/event-dispatcher 反查源头。
composer why-not vendor/package:version 是唯一能定位死锁点的命令
当报错出现 Conclusion: don't install vendor/package:v2.0 时，别猜，直接执行：
composer why-not vendor/package:v2.0
它会输出完整拦截链，例如：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
laravel/framework 10.32.1 requires symfony/console (^6.2) mytool/sdk 2.1.0 requires symfony/console (~5.4.0) → laravel/framework cannot be installed with mytool/sdk
关键点：
- 输出中带
requires的行才是硬性约束，带conflicts的是软性排除 - 如果某行显示
root requires，说明是你自己在composer.json里写的冲突约束 - 若结果为空，说明该包根本没被任何依赖声明拉入，可能是缓存残留，先
composer clear-cache
dev-main / dev-develop 是隐形循环诱因
这类开发分支没有语义化版本锚点，Composer 解析时会尝试取最新 commit，极易导致：
- 今天
dev-main依赖psr/log:^3.0，明天作者提交后变成^2.0 - 另一个
dev-develop包也依赖psr/log，但解析时取了不同快照，版本对不上
解决方法只有两个：
- 改用稳定标签：查 Packagist 页面，换成
composer require vendor/package:^2.5这类明确范围 - 彻底隔离：用
composer create-project单独建工具项目，不混进主项目依赖树
真实项目里，超过三层间接依赖 + 一个 dev-main，基本就等于主动开启依赖地狱模式。
