composer提示版本冲突怎么办_composer依赖冲突解决方案【笔记】

composer依赖冲突需先用composer why-not定位阻塞包，再检查minimum-stability、platform配置及php/扩展环境一致性，优先分批升级、收窄版本范围，避免ignore-platform-reqs和replace等危险操作。

composer install 报错 “Conclusion: don’t install xxx” 怎么办

这是最典型的依赖冲突提示，composer install 或 composer update 时出现一堆 “Conclusion: don’t install…” 或 “it requires xxx but you have yyy” 的回溯链，本质是 Composer 找不到一组能同时满足所有包版本约束的解。

• 先运行 composer why-not vendor/package:version（比如 composer why-not laravel/framework:v10.0.0），它会告诉你哪个已安装包在阻止该版本被安装
• 检查 composer.json 中的 "minimum-stability" 和 "prefer-stable" 设置：如果设了 "minimum-stability": "dev"，可能意外拉入不兼容的开发版；建议显式设为 "stable" 并开启 "prefer-stable": true
• 不要盲目加 --ignore-platform-reqs，它绕过 PHP/扩展版本检查，可能让项目跑起来但实际运行时报错

require 两个包却提示它们互斥，怎么协调

比如 A 包要求 "monolog/monolog": "^2.0"，B 包要求 "monolog/monolog": "^3.0"，Composer 就无法共存。

• 查看两者的最新稳定版是否已支持同一主版本：用 composer show monolog/monolog 看当前锁定版本，再查 A/B 包的 gitHub README 或 packagist 页面，确认它们各自对 monolog 的 require 字段是否已更新
• 如果 A 包尚未适配 Monolog 3，而你又必须用 B 包，可临时 fork A 包、修改其 composer.json 中的 monolog 约束（如改为 "^2.0 || ^3.0"），然后在自己项目的 repositories 中指向这个 fork
• 避免用 replace 或 provide 强行“冒充”兼容——这会让依赖解析失效，后续 update 更难处理

composer update 卡住或耗时极长

这不是报错，但属于冲突的隐性表现：Solver 正在穷举组合，说明约束太紧或版本范围太宽（比如用了 "*" 或 "dev-main"）。

• 运行 composer update --dry-run -v，加上 -v 可看到 solver 每一步尝试，快速定位哪几个包在反复回溯
• 把模糊版本号收窄：把 "^1.0" 换成 "^1.5"，或把 "dev-develop" 换成具体 commit hash（"dev-develop#abc123"）
• 若项目长期未 update，别直接 composer update，改用 composer update vendor/package --with-dependencies 分批升级，减少 solver 空间维度

本地能装，CI 上失败，平台差异怎么排查

常见于本地 PHP 8.2、CI 用 PHP 8.1，或本地有 ext-intl、CI 没装。

• 在 CI 脚本开头加 php -v && php -m | grep -E 'intl|mbstring'，确认运行时环境一致
• 检查 composer.json 的 "platform" 配置：如果写了 "php": "8.2.0"，但 CI 是 8.1，Composer 会拒绝安装需要 8.2+ 的包；应删掉 "platform" 或按 CI 环境设为最低支持版本
• composer.lock 必须提交进 Git，且确保生成它的 Composer 版本不低于 CI 使用的版本（例如 lock 文件由 Composer 2.5 生成，CI 不能用 2.2）

真正麻烦的不是报错本身，而是冲突根源藏在间接依赖里——composer show --tree 输出可能有 5 层深，其中第三层某个 dev 分支包悄悄锁死了某个组件的旧版。这时候得一层层 composer why 往上摸，而不是盯着最外层的 require 行改。