Composer 的依赖冲突是可预测、可拦截、可修复的工程问题；报错本质是版本约束间存在逻辑矛盾，SAT 求解器已穷尽路径后判定无解。
Composer 的依赖地狱不是玄学，是可预测、可拦截、可修复的工程问题——关键在于别等 composer install 卡死才动手。
看懂 conflict 报错到底在说什么
当 Composer 报出 Conclusion: don't install vendor/package v2.0 或 Root composer.json requires vendor/other ^3.0, but that version conflicts with...，它其实是在告诉你：当前所有约束条件无法同时满足，SAT 求解器已穷尽可能路径后放弃。
- 这不是“包坏了”，而是你写的版本约束之间存在逻辑矛盾（比如 A 要 PHP >=8.1，B 要 PHP
- 别急着删
vendor/或composer.lock——先用composer why-not vendor/package:version定位谁在拦路 - 如果报错里反复出现
symfony/polyfill-*或psr/*，大概率是底层工具链（如 PHPUnit、PHPStan）和框架版本错配，而非业务代码问题
用好 composer show --tree 和 composer depends
依赖树不是摆设，它是唯一能看清“谁拖了谁后腿”的地图。执行 composer show --tree 后重点扫三类节点：
- 重复出现的包（如两个不同版本的
guzzlehttp/psr7），说明有间接依赖未对齐 - 带
(required by ...)标注的包，点开它上游是谁，往往冲突源头藏在第三层依赖里 - 标为
dev-main或dev-develop的包——它们没有语义化版本锚点，极易引发解析漂移
再配合 composer depends symfony/console 反查谁在拉低版本，常能揪出某个测试工具或部署脚本偷偷锁死了核心组件。
别硬刚冲突，优先降级兼容或隔离工具链
不是所有冲突都值得花半天去“解”。多数真实项目中，更快的解法是绕开，而不是攻克：
- 想装
laravel/breeze但提示与laravel/framework冲突？查 Packagist 页面，改用composer require laravel/breeze:^1.26（Laravel 9 兼容版），而非硬上 v2.x - 需要 Rector 或 PHPStan 却被项目依赖卡住？用
composer create-project rector/rector rectortool --no-dev独立安装，再通过路径调用：php rectortool/bin/rector process src/ --config rector.php - CI 中频繁因缓存导致解析失败？在构建脚本开头加
composer clear-cache+composer update --prefer-dist --no-interaction，避免本地残留影响远程环境
锁定 ≠ 安全，composer.lock 需定期验证
composer.lock 是保障一致性的重要文件，但它不会自动识别过时或不安全的传递依赖。一个容易被忽略的事实是：哪怕 lock 文件没变，只要某依赖包在 Packagist 上撤回了一个含漏洞的 patch 版本（如 v1.2.3），Composer 下次 install 仍可能拉到它——因为 lock 里记录的是 hash，不是发布状态。
- 每月至少运行一次
composer audit（需 Composer 2.5+），它会联网比对已知 CVE - 团队中若有人手动编辑过
composer.lock（比如删掉某行 hash），务必用composer validate检查合法性，否则install可能静默失败 - PHP 版本升级后（如从 8.1 → 8.3），不要只跑
update，先执行composer prohibits php:*.*看哪些包明确拒绝新版本
真正难的不是解决某次冲突，而是让下次冲突发生前就被约束捕获——比如在 CI 中强制检查 composer show --outdated 并阻断高危更新，或者用 conflict 字段提前声明不兼容组合。这些动作不显眼，但省下的调试时间，够写三页业务逻辑。
