Composer依赖死循环表现为执行install/update时出现嵌套超限、内存耗尽或卡在Resolving dependencies，根源是版本冲突导致求解器回溯爆炸；可用composer why-not定位冲突源头，通过replace/provide替代冲突包，避免硬指定版本。
Composer 依赖死循环的典型表现
当你执行 composer install 或 composer update 时，如果出现类似 Maximum function nesting level of '256' reached、Allowed memory size exhausted，或卡在 Resolving dependencies 长时间无响应，大概率是依赖图中存在版本约束冲突引发的回溯爆炸——不是语法错误，而是 solver 在反复尝试满足嵌套 require（比如 A → B → C → A）时陷入指数级搜索。
用 composer why-not 定位强制指定的源头
死循环往往源于某个包被多个上游间接要求不同版本，而你又在 composer.json 里硬写了冲突版本。先别急着删 require，用下面命令查清谁在“拉扯”：
composer why-not vendor/package:v1.2.3
它会列出所有阻止该版本安装的依赖路径，例如：
-
my/projectrequiresvendor/package (^1.0) -
other/librequiresvendor/package (2.0.0)
这时你就知道：不是 vendor/package 本身有问题，而是 other/lib 和你的项目对它的版本诉求不可同时满足。
强制指定版本前必须做三件事
直接在 composer.json 的 require 里写死 "vendor/package": "1.2.3" 很危险，可能让 solver 更难收敛。动手前确认：
- 检查该包是否已被其他依赖通过
conflict声明明确排除（看其composer.json） - 运行
composer prohibits vendor/package:1.2.3查是否有直接冲突规则 - 临时加
--no-update修改composer.json后，用composer update --dry-run vendor/package验证是否真能解出
如果 --dry-run 报错说 “Your requirements could not be resolved”，说明这个版本在当前依赖树下根本不可达，硬指定只会让死循环更顽固。
真正有效的破局点：用 replace 和 provide 跳过冲突包
当某个包（如 monolog/monolog）被两个不兼容的库分别 require，且你无法升级其中一方时，可用 replace 告诉 Composer：“这个包我用自己的实现/空桩代替”。例如：
{
"replace": {
"some/conflicting-package": "*"
}
}
或者更精准地用 provide 声明你的项目已提供某接口能力，让依赖它的包跳过安装：
{
"provide": {
"psr/log-implementation": "1.0.0"
}
}
这比暴力 require 版本更底层、副作用更小——solver 不再试图下载和解析那个包，自然消除了嵌套路径。
实际中最容易被忽略的是：很多死循环其实源于 dev-only 依赖（如 phpunit/phpunit）意外进入生产依赖图。务必确认 composer install 是否带了 --no-dev，以及 autoload-dev 是否误引入了测试工具链到主逻辑中。
