Composer 解决依赖冲突靠明确约束与人工干预，不自动修复；报错时需分析 conflict 信息，用 why-not 和 depends --tree 定位冲突源，理解 suggests 非依赖，最终通过收缩约束、升级主包或显式锁定中间版本解决。
Composer 解决依赖冲突不是靠“自动修复”，而是靠明确约束 + 人工干预。它不会替你决定用哪个版本，只告诉你哪里不兼容、为什么装不上。
composer install 或 update 报错时，先看 conflict 信息
错误里出现 Conclusion: don't install 或 can only install one of 就是典型的包冲突。Composer 已经推导出：当前 composer.json 中的版本约束无法同时满足所有 require 的包及其子依赖。
- 不要直接删
vendor或composer.lock重试——这不会绕过逻辑矛盾 - 运行
composer why-not vendor/package:version查具体哪个包在阻止安装（例如composer why-not laravel/framework:v10.0） - 用
composer depends --tree vendor/package看谁在依赖该包，以及它的版本路径
理解 suggests 不是依赖，只是推荐扩展
suggests 字段出现在 composer show vendor/package 输出末尾，或 composer install 结束后的提示里。它不参与版本解析，也不影响安装成功与否——只是作者写的“如果你用这个包，可能也想试试这些”。
-
suggests不会触发自动安装，也不会被composer update拉取 - 它常被误读为“缺失依赖”，但实际缺失的是功能，不是合法性；比如
monolog/monologsuggestaws/aws-sdk-php，只是说“配了 AWS SDK 才能发日志到 CloudWatch”，没装也不报错 - 若某
suggests包真被项目用到，需手动加进require并解决其版本兼容性
真正解决冲突：收缩约束 or 升级主包
冲突根源通常是两个包要求互斥的同一依赖版本（如 A 要 symfony/console:^5.4，B 要 symfony/console:^6.2）。这时候得做选择：
- 检查是否某个包已废弃：运行
composer show vendor/package看abandoned字段，换成维护中的替代品 - 放宽约束？谨慎！把
"laravel/framework": "10.0.*"改成"10.*"可能引入 BC break；更安全的是用^10.0并确认 changelog - 锁定中间版本：如果 A 和 B 分别需要 symfony/console 5.4 和 6.2，而你项目只用到 console 的基础命令功能，可尝试在
composer.json中显式 require"symfony/console": "5.4.39"，再跑composer update看是否能共存（Composer 会按需降级其他包）
{
"require": {
"laravel/framework": "^10.0",
"spatie/laravel-backup": "^8.0"
},
"require-dev": {
"symfony/console": "5.4.39"
}
}
冲突的本质是语义化版本边界与真实 API 兼容性的落差。哪怕 composer 告诉你 “no valid candidates”，也未必是 bug——更可能是你正试图把 PHP 8.3 的包和 PHP 7.4 的运行环境硬凑在一起。
