Composer安装包冲突本质是依赖约束无交集，应先用composer why-not定位阻断链，再结合--dry-run验证，优先降级冲突包而非强制绕过校验。
Composer 安装包冲突不是“运气不好”，而是依赖图里存在不可满足的约束条件——直接看 composer update --dry-run 和 composer why-not 就能定位根因，别急着删 vendor 或强制 --ignore-platform-reqs。
为什么 composer install 报 “Your requirements could not be resolved”
这不是 Composer 故意卡你，而是它在尝试为所有包找到一组同时满足全部 require 声明的版本。只要任意两个包对同一个依赖（比如 symfony/console）提出了互斥范围（如 "^5.4" vs "^6.2"），就会失败。
- 常见诱因：项目里手动加了一个高版本包，但已有包只兼容旧版（例如引入
laravel/framework 11.x，而spatie/laravel-backup还未适配） - 注意
composer.json中platform配置（如"php": "8.1.0"）也会参与约束求解，和实际运行环境不一致时会误判 - 错误信息末尾的
Root composer.json requires ...行是关键线索，它说明谁在“提需求”，但真正挡路的往往是下游间接依赖
用 composer why-not 快速揪出冲突源头
比反复猜哪个包有问题高效得多。给定一个你想装却装不上的包+版本，它会列出所有阻止该组合成立的已存在依赖。
- 执行
composer why-not guzzlehttp/guzzle:7.9.0，输出可能显示：myapp/core v2.3.1 requires guzzlehttp/guzzle ^6.5—— 这就锁死了你不能升到 7.x - 如果提示
no installed package depends on ...，说明冲突来自platform或 rootrequire的显式声明，回头检查composer.json的require和config.platform - 配合
--tree（如composer why-not --tree guzzlehttp/guzzle:7.9.0）可展开依赖链，看清是哪一层传递了限制
升级前必做的三步验证
盲目 composer update xxx 可能引发新冲突或破坏功能。先做最小验证：
- 跑
composer update --dry-run --with-dependencies xxx：只算不改，看是否仍冲突、影响哪些其他包 - 检查目标包的 CHANGELOG 或 GitHub Issues，确认它是否已声明兼容你当前的关键依赖（如
doctrine/dbal版本） - 临时建测试分支，
composer require xxx:desired-version --no-update && composer update --with-all-dependencies，把变更隔离出来测
慎用 --force 和 --ignore-platform-reqs
它们绕过校验，但不会消除真实冲突——只是把问题推迟到运行时报错（比如 Call to undefined method 或 Class not found）。
-
--ignore-platform-reqs仅应出现在 CI 环境中 PHP 版本与本地不一致时；生产环境硬上等于埋雷 -
--force（或--no-interaction强制覆盖）可能让 Composer 选一个看似“可行”但实际不稳定的版本组合，后续composer update会更难收敛 - 真要破局，优先考虑降级冲突包（如用
spatie/laravel-backup:^8.0替代^9.0），而不是强行拉高整个栈
最常被忽略的一点：Composer 的冲突解析基于语义化版本号，但有些包没严格遵循 SemVer（比如小版本改了接口），此时 why-not 能看到约束，却看不出“为什么这个版本其实不能用”。遇到这种包，得去翻它的提交记录或测试用例，而不是只信 composer.json 里的 require。
