真正有效的解决方式是用composer update --dry-run -v定位because链路根因，再结合composer why-not查阻断依赖，同时排除require-dev和config.platform干扰；删lock前须备份、清缓存并确认镜像源有效。
直接删 composer.lock 和 vendor/ 并不能解决冲突，反而会让 Composer 从零开始瞎试，大概率触发更隐蔽的约束矛盾。真正有效的简化，是逐步剥离干扰项，把冲突暴露在最小可验证路径上。
先用 --dry-run -v 看清 Composer 想干什么
执行 composer update --dry-run -v 不改任何文件，但完整走一遍 SAT 求解过程。关键看输出末尾的 Because... 链路，它会明确写出第一个不可满足的约束，比如：
Because package-a v2.1 requires symfony/console ^5.4, and package-b v3.0 requires symfony/console ^6.0.
这个「Because」就是冲突根因，不是猜测，是求解器给出的逻辑断言。
- 别跳过
-v，没它就看不到具体哪条路径卡住 -
--dry-run比install更早暴露问题，避免被已安装状态误导 - 如果输出里反复出现同一个包（如
monolog/monolog），它大概率是冲突枢纽
用 composer why-not 定位谁在拦路
composer why-not 是最接近“问话”的命令：你想装某个版本，它告诉你谁不让装。必须带完整版本标识，例如：
composer why-not monolog/monolog:^2.0
它会输出类似：
laravel/framework v10.42.0 requires monolog/monolog (^1.25 || ^2.0) package-x v1.3.0 requires monolog/monolog 1.26.1
注意第二行——package-x 的硬锁定才是真拦路虎。
- 只写
monolog/monolog会报Package not found，必须加版本号或约束符 - 如果目标包不在当前
composer.json或composer.lock中，它无法分析 - 输出里带
(for spatie/laravel-backup v7.2.0)这种括号，说明该约束来自间接依赖，得继续往上查
隔离 require-dev 和平台配置干扰
很多冲突其实来自测试工具链或伪造的 PHP 环境。先排除它们：
- 加
--no-dev再跑一次composer update --dry-run -v，看冲突是否消失 - 检查
composer.json的config.platform字段，临时注释掉，再试 - 运行
php -v和composer diagnose，确认实际 PHP 版本与config.platform.php是否一致 - 若冲突消失，说明是
phpunit/phpunit或phpstan/phpstan这类工具拉高了依赖要求
删 composer.lock 前必须做三件事
删锁文件本身不危险，危险的是删完立刻 install。必须同步完成：
- 备份原锁文件：
cp composer.lock composer.lock.bak - 确认镜像源干净：运行
composer config -g repo.packagist，确保返回的是有效 HTTPS URL（结尾带/） - 清缓存：
composer clear-cache，否则旧元数据仍参与解析
做完这三步再 composer install，才能生成真正对齐当前约束的新 composer.lock。否则哈希校验失败、回退到官方源、甚至静默忽略镜像，都是常见副作用。
复杂点在于：冲突常藏在 require-dev 里，而 composer show --tree 默认不展开 dev 依赖；容易被忽略的是 config.platform 伪造的环境信息，它会让 Composer “以为”自己能装高版本包，实际运行时却失败。
