Composer依赖冲突需先查看错误信息明确冲突包及版本，再用composer why和depends分析依赖链，检查composer.json版本约束与lock文件，最后通过调整版本、更新依赖或替换包解决。
Composer 依赖冲突是 PHP 项目中常见的问题，通常表现为安装或更新包时提示版本不兼容。解决这类问题需要系统性地分析依赖关系，并做出合理决策。
查看冲突信息
当 Composer 报错时，首先仔细阅读错误输出。它会明确指出哪个包与当前环境或其他依赖存在版本冲突。例如：
Your requirements could not be resolved to an installable set of packages.这类提示后通常会列出冲突的包名、期望版本和实际可用版本。重点关注以下几点：
- 哪个包触发了冲突
- 该包要求的版本范围
- 当前已安装或锁定的版本
- 是否存在平台依赖（如 PHP 版本、扩展）不满足
使用 composer why 和 composer depends 分析依赖链
借助 Composer 内置命令可以追溯依赖来源：
- composer why vendor/package：查看某个包为何被安装，以及谁依赖了它
- composer depends vendor/package：查看哪些包依赖了指定包
通过这两个命令，能清晰看到依赖链条。比如 A 依赖 B^2.0，C 依赖 B^1.0，就会导致冲突。此时可判断是否可以升级 C 或降级 A 来协调。
检查 composer.json 和 lock 文件
手动审查项目的 composer.json，确认 require 和 require-dev 中的版本约束是否过于严格或过时。常见问题包括：
- 指定了无法共存的大版本（如同时要求 monolog/monolog:^1 和 ^2）
- 第三方包尚未支持当前 PHP 版本
- lock 文件残留旧记录导致解析失败
必要时可删除 composer.lock 和 vendor 目录后重新运行 composer install，让 Composer 重新计算最优依赖树。
尝试解决方案
根据分析结果采取对应措施：
- 调整版本约束：将冲突包的版本放宽为兼容范围，如从 ^1.5 改为 ^1.5 || ^2.0（若实际兼容）
- 更新主依赖：升级依赖冲突包的上层包，可能新版本已支持更高版本的子依赖
- 替换不可维护包：若某包长期不更新且阻碍升级，考虑寻找替代方案
- 使用 platform config 模拟环境：通过 config.platform 配置模拟 PHP 版本或扩展，绕过因环境误判导致的冲突
基本上就这些。关键是理清依赖路径，结合项目实际情况做取舍。Composer 的依赖解析器很强大，多数冲突可通过合理调整版本或升级包解决。
