执行 composer why-not vendor/package-name:1.2.3 可精准定位阻止该版本安装的直接/间接依赖，包括项目自身 require、依赖的 require 或 conflict 声明；若输出为空，则可能是被更宽泛约束（如 ^2.0）间接排除。
composer install 报错 “is not compatible with” 怎么快速定位冲突源
这类错误本质是 composer.json 中某包的版本约束与已锁定或待安装的其他包不兼容。关键不是看报错最后一行，而是要反向查谁在 requires 或 conflicts 里写了硬性限制。
执行以下命令可快速暴露真实冲突链：
composer why-not vendor/package-name:1.2.3
它会列出所有阻止该版本安装的直接/间接依赖项，包括：your-project 自身的 require、某个依赖的 require、甚至某个依赖的 conflict 声明。注意：如果输出为空，说明该版本根本没被任何规则“主动拒绝”，而是被其他更宽泛的约束（如 ^2.0）间接排除。
- 优先检查
composer.lock里已存在的同名包版本，再比对composer.json新增/修改的约束 -
conflict字段常被忽略——有些包会在自身composer.json里写"conflict": {"monolog/monolog": ">=2.0.0"}，这比require更具强制力 - 运行
composer show -t可视化依赖树，但需配合grep过滤，例如：composer show -t | grep -A5 "package-name"
require 和 require-dev 的版本约束为何会互相干扰
表面上 require-dev 只用于开发环境，但 Composer 在解析依赖时**不区分环境**——所有 require 和 require-dev 的约束都会参与统一的 SAT（布尔可满足性）求解。一旦某个 dev 包依赖了 phpunit/phpunit:^9.0，而主项目 require 了 laravel/framework:^8.0（其内部要求 phpunit:^8.0），冲突就立即触发。
-
require-dev中的包若声明了require（非require-dev），这些依赖会被当作“必须满足的全局约束”处理 - 升级
require-dev里的工具类包（如phpstan/phpstan）常意外拉高 PHP 版本要求，进而卡住主框架升级 - 临时解决：用
--no-dev参数跳过 dev 依赖解析，验证是否为 dev 包引发——但这是诊断手段，不是修复方案
使用 ^、~、>= 等版本运算符时的实际行为差异
很多人以为 ^1.2.3 ≈ ~1.2.3，但它们在边界场景下行为不同，尤其涉及预发布版或主版本跃迁时：
-
^1.2.3允许升级到1.999.999，但禁止2.0.0；^0.1.2却只允许0.1.x（因 0.x 被视为不稳定主版本） -
~1.2.3等价于>=1.2.3 ，比 <code>^更保守；而~1.2等价于>=1.2.0 ，这里又和 <code>^对齐了 -
>=1.2.3没有上界，可能装到2.0.0甚至3.0.0，除非其他包用conflict显式拦截
建议：新项目统一用 ^，但对主版本敏感的包（如 symfony/*），显式写死主版本范围更安全，例如："symfony/console": "^5.4 || ^6.0"。
强制降级或绕过冲突的危险操作有哪些
用 composer require vendor/package:1.2.3 --update-with-dependencies 看似能强行指定版本，但极易引发隐性破坏：
-
--ignore-platform-reqs会跳过 PHP/扩展版本检查，可能导致运行时报Call to undefined function -
--force-reinstall不重算依赖图，只是重装，对版本冲突完全无效 - 手动编辑
composer.lock是最危险操作——Composer 下次运行可能回滚或报校验失败
真正可控的方式只有两种：一是用 composer prohibits vendor/package 找出谁在阻止，然后调整那个包的版本；二是用 replace 或 provide 声明虚拟包来满足依赖接口（适用于 fork 替换场景）。
复杂点在于：很多冲突来自传递依赖的传递依赖，你改了 A，B 就报错；改了 B，C 又崩——这时候得靠 why-not 多层追溯，而不是凭感觉删锁文件重装。
