本质是约束无法同时满足，需用composer why-not定位阻断链、composer show --tree查真实依赖结构，并区分conflict（全局拦截）与replace（替代声明）的实际作用。
插件与扩展库的兼容性冲突，本质是 Composer 在解析 composer.json 时发现约束条件无法同时满足——不是网络或权限问题，而是版本、平台要求、conflict 字段或 replace 替代逻辑之间存在硬性矛盾。
用 composer why-not 定位阻断链路
这是最直接有效的起点。它不依赖缓存或锁文件，只看约束本身是否自洽：
- 运行
composer why-not vendor/plugin-name:version（例如composer why-not laravel/telescope:^4.0），输出是倒序链：最后一行是你在composer.json中写的require，往上每行末尾的(required by ...)就是封杀源头 - 如果输出为空，先检查是否漏了
--stability=dev（比如目标是dev-main），或确认镜像已生效且执行过composer clear-cache - 别用
composer depends替代——它只显示谁依赖你，不体现版本限制
检查 composer show --tree 中的真实依赖结构
composer.json 是你的“愿望清单”，而 composer show --tree 才是当前 vendor/ 和 composer.lock 的真实快照：
- 重点关注括号里的标注：
(locked to 5.4.42)表示被强制锁定；(replaced)表示被replace字段替代；(provided)表示该包声明自己提供了某接口或扩展 - 过滤查看关键路径：例如
composer show --tree monolog/monolog | grep -A5 -B5 "guzzlehttp/guzzle"，能快速判断是否因替代关系导致 Guzzle 被跳过 - 若看到某个插件依赖
symfony/console:^6.0，但树里显示symfony/console实际是5.4.42，说明有其他包在拉低版本
验证 PHP 平台与扩展是否真正就位
很多“依赖冲突”其实是环境缺失伪装的：
- 错误信息中出现
ext-dom * -> it is missing from your system或php ^8.1 -> your php version (7.4.33) does not satisfy...，这类报错必须优先解决 - 运行
php -v和php -m | grep -E 'dom|xml|json|mbstring'确认实际加载的扩展和版本 - 注意：某些包的
require写的是"ext-xml": "*"，但实际需要的是 DOM + SimpleXML 两个扩展都启用，缺一不可 - Ubuntu/Debian 用户安装扩展要带 PHP 版本号，例如
sudo apt-get install php8.1-dom php8.1-xml，装错版本不会报错但也不生效
区分 conflict 与 replace 的实际作用
这两个字段不是提示，是硬性规则，但行为完全不同：
-
conflict是全局拦截器：哪怕你没require某个包，只要其他已装包间接拉进来，就会触发拒绝。例如私有插件写了"conflict": {"laravel/framework": ">=11.0"}，而项目里没装 L11，却仍报冲突——大概率是另一个已装包（如spatie/laravel-backup）把 L11 带进来了 -
replace是替代声明：比如symfony/polyfill-mbstring在replace里写明替代ext-mbstring，Composer 就会认为“装了 polyfill = 满足 ext-mbstring 依赖”。但前提是它真能覆盖所有调用路径，否则运行时报Call to undefined function mb_strlen() - 检查方式：进到那个包的源码目录，看它的
composer.json里replace和provide字段到底声明了什么
真正难处理的点在于：conflict 和 replace 往往藏在第三方包的 composer.json 里，你改不了，只能绕开或降级上游。这时候，composer why-not 输出的最后一行“根 require”就是你唯一可控的出口。
