Composer install 报错“don’t install packageA v1.2.0”本质是依赖约束冲突，需用 composer why-not 定位阻塞源，检查 conflict 字段、require-dev 引入的间接依赖及私有仓库配置，避免删 lock 文件或盲目升级。
composer install 报错 “Conclusion: don’t install packageA v1.2.0” 怎么办
这是 Composer 依赖解析失败最典型的提示，本质是锁文件 composer.lock 要求的版本与当前 composer.json 中声明的约束、或已安装包的实际版本存在逻辑矛盾。不是“某个包装不了”，而是整个依赖图无法同时满足所有约束。
- 先运行
composer why-not vendor/package-name version，它会明确告诉你哪个已存在的依赖（甚至间接依赖）在阻止该版本安装 - 不要直接删
composer.lock重装——这可能掩盖真实冲突点，且破坏团队环境一致性 - 如果是开发中临时想试一个新版本，用
composer require vendor/package:dev-main --with-all-dependencies比盲目升级更可控 - 注意
conflict字段：有些包在composer.json里写了"conflict": {"php": "8.3.0"}这类硬限制，PHP 版本不匹配也会触发同类报错
require 和 require-dev 的依赖互相打架怎么查
require-dev 里的包（比如 phpunit/phpunit）虽然只在本地开发时需要，但它声明的依赖仍参与全局版本解析。一旦它拉入一个和生产依赖不兼容的 symfony/console 版本，整个 install 就会失败。
- 运行
composer show --tree查看完整依赖树，重点关注 dev-only 包引入的“意外分支” - 用
composer depends vendor/package反查谁拖进了某个可疑版本 - 若确认某 dev 包只是测试用且无 runtime 影响，可尝试加
--no-dev参数跳过它来验证是否真由它引发冲突 - 切忌在
require-dev里写宽泛版本如"^5.0"，尤其对核心组件；应尽量锁定小版本或使用~限定补丁级更新
用了 private repo 或 fork 后依赖解析变慢还报错
私有仓库（如 GitLab 私仓、GitHub fork）若未正确配置 repositories 类型或缺少 dist 信息，Composer 会退回到低效的 source 模式克隆，同时可能因分支别名（如 dev-feature/x）与版本约束不匹配而误判兼容性。
- 确保
repositories中指定了"type": "vcs"，并检查 URL 是否可被 Composer 正确识别为 Git 仓库 - Fork 的包如果改了
composer.json中的name或version，必须同步更新composer.json的require条目，否则 Composer 认不出这是同一包 - 避免在
repositories里混用package和vcs类型——前者需手动维护完整元数据，极易出错 - 私仓响应慢时，Composer 可能超时中断并缓存错误状态，此时清缓存
composer clear-cache比反复重试更有效
依赖冲突从来不是“哪个包有问题”，而是版本约束之间的隐含假设被打破。最常被忽略的是：你没动 composer.json，但别人提交的 composer.lock 已悄悄绑定了某个 PHP 扩展版本或平台特性，而你的本地环境缺那条扩展——这时候报错信息里根本不会提 extension，只说“can’t resolve”。
