composer why-not输出是反向依赖链，需从最后一行（root requires）倒推，重点看conflicts行和最终指向的已安装包或PHP/扩展约束。
composer why-not 显示一堆嵌套依赖，怎么读？
它输出的不是“谁拦你”，而是“所有拒绝理由链”。每行末尾的 (required by ...) 是向上追溯的起点，得从最后一行开始倒着看——最后一行才是你的 composer.json 根依赖。
常见误读：看到某行写 conflict with foo/bar (>=2.0) 就以为是 foo/bar 在作怪。其实那是它自己声明的 conflict 规则，Composer 是照章办事，不是瞎拦。
- 先确认目标版本是否真被需要：比如
composer why-not guzzlehttp/guzzle:^8.0，再对比当前composer show guzzlehttp/guzzle实际装的是哪个版本 - 如果某行显示
laravel/framework v10.32.0 -> requires symfony/console ^6.4，而另一行是package-x v2.1 -> requires symfony/console ^5.4，那冲突点就落在symfony/console上，不是guzzlehttp/guzzle本身 - 注意
require-dev包也会参与解析——哪怕你只跑composer update不带参数，phpunit/phpunit的约束可能把symfony/console卡死在 5.x
composer install 报 “Root requires X but Y is installed”，怎么办？
这是典型的“树顶冲突”：你改了 composer.json 里的根依赖，但 composer.lock 还锁着旧版本，或者本地 vendor/ 已装包和 lock 不一致。
别急着删 vendor/ 或 composer.lock。它们是问题的证据，不是病灶。
- 先运行
composer install --dry-run，看预演里哪条路径断了；如果只是本地环境不一致，直接composer install（它严格按 lock 装）就能过 - 如果确定要升级，用
composer update vendor/package-name精准更新单个包，避免全量重算导致其他包意外降级 - 团队协作中拉了新代码后报这个错，大概率是别人提交了新的
composer.json但没连带提交composer.lock，此时应先git checkout -- composer.lock恢复 lock，再composer install
^1.2.3 和 ~1.2.3 到底差在哪？
差异直接影响能否找到交集版本。^ 允许主版本内任意小/补丁升级（^1.2.3 ≡ >=1.2.3 ），~ 只允许补丁级升级（~1.2.3 ≡ >=1.2.3 ）。
写宽松前，先查对方是否真做语义化发布。很多包标着 v2.0.0 却在小版本里破坏 API，这时 ^2.0 就是坑。
- 若 A 包 require
"monolog/monolog": "^1.25"，B 包 require"monolog/monolog": "~2.9.0"，它们无交集——~2.9.0最多到2.9.9，而^1.25死守 1.x - 去 Packagist 查
monolog/monolog的发布记录，找一个同时被双方接受的版本，比如2.9.3同时满足^2.0和>=2.8.0，那就手动锁死："monolog/monolog": "2.9.3" - 不要盲目写
"^1.25 || ^2.10"，除非你代码真能同时跑通两个大版本的 API；否则只是把冲突从安装期拖到运行时报错
CI/CD 里依赖总出问题，怎么稳住？
CI 环境最怕 dev-only 包反向污染主依赖选择。比如 orchestra/testbench 内部硬绑 Laravel 9，而你主项目用 Laravel 10，composer update 就会卡死。
关键不是让 CI 更“强”，而是让它更“像生产”。
- CI 中必须用
composer install --no-dev --optimize-autoloader，否则测试工具的依赖会参与解析，把主流程拖下水 - 若某个 dev 包持续引发冲突（如
phpunit/phpunit和框架共享sebastian/exporter），考虑用config.platform做虚拟锚点：{"config": {"platform": {"phpunit/phpunit": "9.6.13"}}，它不装包，只提供版本参考 - 本地开发用
composer update无妨，但 CI 的每次构建都应基于干净的composer.lock，且不执行update—— 它只负责install，验证 lock 是否可靠
真正难的不是命令怎么敲，而是判断哪一层约束该松、哪一层该硬。比如 conflict 字段一旦写进私有包，哪怕你没 require 它，只要其他已装包间接拉进来，就会全局触发。这种隐式生效的规则，最容易在上线前夜才暴露。
