Composer不会自动解依赖冲突，需用composer why-not定位阻断源；require-dev常引发隐式冲突，应注释后验证；composer show --tree可揭示多版本间接依赖路径，避免误删被autoload或反射调用的包。
别急着弃用任何包——90%的“必须删包”诉求，其实源于没看清谁在真正卡住依赖解析。 Composer 不会因为你删了一个包就自动解出新方案；它只按约束找交集，找不到就停。所谓“弃用”，往往是诊断不到位时的误操作。
composer why-not 一查就定位阻断源
报错里出现 Conclusion: don't install vendor/package:vX.Y.Z？这不是模糊提示，是明确拒绝信号。直接问 Composer 谁在拦路：
- 运行
composer why-not vendor/package:vX.Y.Z（把版本换成报错里的具体值） - 输出中第一行通常是你的项目本身，比如
your-project-name dev-main requires guzzlehttp/guzzle (^6.5)——说明是你自己的composer.json写死了冲突约束 - 若输出为空，不是没冲突，而是该版本根本不在 Packagist 当前通道（比如只存在于
dev分支但你没配"minimum-stability": "dev"） - 注意：别用
composer why替代——它只查已安装包的来源，不回答“为什么不能装”
require-dev 是隐形冲突推手
很多冲突藏在 require-dev 里，比如 phpunit/phpunit 或 friendsofphp/php-cs-fixer，它们常带高 PHP 版本或新扩展要求，却在 composer install 阶段全程参与解析。
- 执行
composer update --dry-run -v后，盯住最后 10 行，如果反复出现同一组包回溯（如package-a → package-b → package-a），大概率是require-dev引入了隐式闭环 - 临时注释掉
require-dev区块，再跑composer update --dry-run，看冲突是否消失——能快速验证是否为 dev 工具引发 - 不要删
vendor/或composer.lock来“重试”，它们是诊断依据；删了反而掩盖真实依赖快照
composer show --tree 揭露间接依赖链
你没写 symfony/console，但它频繁出现在冲突日志里？说明它是被某个中间包拉进来的。靠树状展开才能看清路径：
- 运行
composer show --tree vendor/package（比如composer show --tree guzzlehttp/guzzle），每行末尾的(locked to X.Y.Z)是当前锁定版本 - 配合
grep快速过滤：例如composer show --tree monolog/monolog | grep "symfony/.*console"，确认是否多个上游对同一枢纽包提了不同要求 - 若某包在树中多次出现且版本不一致（如一次是
^5.4，一次是^6.0），那就是冲突根因——不是包本身有问题，是它的上游没对齐
真正需要“弃用”的，往往不是业务相关包，而是那些强行用 replace 或 conflict 干预依赖逻辑的私有配置、过时 SDK、或未维护的 dev-only 工具。它们不提供功能价值，只增加解析负担。复杂点在于：有些包看似可删，实则被 autoload 或运行时反射调用，删了会触发 Class not found——所以先查 composer show --tree，再动刀。
