composer如何解决依赖冲突？（常见错误处理方法）

composer 依赖冲突本质是约束不一致，需用 composer why-not 定位阻塞源，优先精准更新、检查 changelog 和私有源配置，而非直接删 lock 文件。

composer install 报错：“Conclusion: don’t install packageA”

这是 Composer 依赖解析失败最典型的提示，本质是锁文件（composer.lock）里记录的版本与当前 composer.json 中声明的约束冲突，或者多个包对同一依赖提出了互斥要求。

别急着删 lock 文件重装——它本意是保证环境一致性。先用 composer why-not <code>packageX 查清谁在阻止安装，比如：

composer why-not guzzlehttp/guzzle:^8.0

会列出所有间接依赖中强制要求 guzzlehttp/guzzle 必须是 ^7.0 的包。

• 如果只是本地开发想快速验证，可临时加 --ignore-platform-reqs 跳过 PHP 扩展或版本检查（但上线前必须去掉）
• 若报错涉及 php 版本不匹配，检查 config.platform.php 是否被硬编码成旧版本
• 某些包（如 laravel/framework）会通过 conflict 字段主动拒绝其他包的特定版本，得去它的 composer.json 里确认

require 和 require-dev 冲突时怎么破？

require-dev 里的包也会参与依赖解析，哪怕只在测试时用。常见陷阱是：生产环境跑 composer install --no-dev 没问题，但 CI 流水线里执行 composer install 却失败——因为某个 require-dev 包（比如 phpunit/phpunit）拉了和主项目不兼容的 symfony/console。

• 用 composer show --tree <code>vendor/package 看清依赖树层级，定位是哪个 dev 包带偏了
• 如果确定某 dev 包只用于本地，可改用 require + autoload-dev 分离逻辑，而非直接写进 require-dev
• 升级 phpunit 前务必查它对 php 和 ext-json 的真实要求——有些小版本会悄悄提高最低 PHP 版本

composer update 更新后功能异常，但没报错

没报错 ≠ 没问题。composer update 默认更新所有包到满足约束的最新版，可能触发语义化版本中的“次要更新”（minor），而某些包的 minor 版本实际包含破坏性变更（比如 monolog/monolog v2 → v3 的 handler 接口变动）。

• 永远优先用 composer update <code>vendor/package 精准更新，而不是全量 update
• 更新前先看 CHANGELOG：很多包把 breaking change 写在 gitHub Release 的 “Breaking Changes” 小节，不是 README 里
• 如果用了 ^ 版本约束（如 "guzzlehttp/guzzle": "^7.0"），Composer 可能升到 7.9，但某些中间件行为在 7.5+ 已静默变更，得翻 PR 记录

私有包和 packagist.org 同名包冲突

当你的私有 Git 仓库也叫 myorg/utils，而 Packagist 上恰好有个同名废弃包，Composer 可能优先拉错源，尤其当你没配 repositories 顺序时。

• 在 composer.json 顶部明确定义私有源，并设 "packagist.org": false 关闭默认源（慎用，需确保所有依赖都可在私有源或自定义源找到）
• 用 composer config repositories.myorg vcs https://git.example.com/myorg/utils.git 注册后，再 require 时加上 -vvv 看 Composer 实际从哪下载
• 私有包的 version 字段必须和 tag 严格一致；如果打的是 v1.2.3 tag，但 composer.json 里写 "version": "1.2.3"，Composer 会认为这是不同包

依赖冲突从来不是“能不能装上”的问题，而是“谁该听谁的”——Composer 的 resolver 会穷举所有组合，但你的 composer.json 约束、lock 文件快照、平台配置、甚至 Git tag 格式，都在暗中投票。稍有不一致，它就卡住不动。