Composer依赖冲突需倒读composer why-not输出定位源头，用composer update vendor/package --with-dependencies精准升级，勿删composer.lock，优先composer install --dry-run预演。
Composer 更新时卡在 Resolving dependencies 或报 Your requirements could not be resolved，不是网络慢或配置错，是依赖约束本身没有交集——它根本算不出一个合法解。
用 composer why-not 定位谁在封杀目标版本
这个命令输出的是“拒绝理由链”，不是因果图。必须从最后一行（通常是你的根项目 myapp/myproject dev-main）开始倒着读，才能看清冲突源头。
- 如果某行末尾写着
(conflict with foo/bar >=2.0)，说明foo/bar自己声明了conflict规则，Composer 是照章执行，不是误判 - 若输出为空或只显示
nothing，说明你要装的版本压根没发布过，不是冲突，是版本不存在 - 注意
require-dev包也参与解析：比如phpunit/phpunit要求sebastian/exporter ^4.0，而主框架要^5.0，它们会互相拖住
用 composer update vendor/package --with-dependencies 精准升级
这不是“强制安装”，而是让 Composer 在最小影响范围内重算该包及其直系依赖。比全量 composer update 安全得多。
- 必须显式写包名，不能带
^、~或引号，例如：composer update monolog/monolog --with-dependencies - 加
--with-dependencies是关键：它允许升monolog/monolog所需的最小依赖集，但不会动phpunit这类无关项 - 如果不加，Composer 常直接拒绝执行，报 “无法满足要求”
- 升级后立刻
git diff composer.lock，确认只有预期包和其直系依赖被改——多改一个symfony/polyfill-*都可能埋隐患
别删 composer.lock，先跑 composer install --dry-run
composer.lock 是当前已验证可行的依赖快照，不是障碍。删它等于扔掉唯一线索，重来一遍只会更难定位。
-
composer install --dry-run能预演冲突点，看到哪条路径断了，比盲等Resolving dependencies有用得多 - 如果只是本地环境不一致（比如 PHP 版本或扩展不同），直接
composer install就能过——它严格按 lock 文件安装 - 团队协作中拉新代码后报
Root requires X but Y is installed，大概率是别人提交了新composer.json却漏提composer.lock，此时应先git checkout -- composer.lock恢复再装
^1.2.3 和 ~1.2.3 的差异真会影响能否解出依赖
很多人以为这只是写法风格问题，其实它直接决定版本范围是否有交集。
-
^1.2.3等价于>=1.2.3 ，允许所有 1.x 小版本 -
~1.2.3等价于>=1.2.3 ，只允许补丁级更新 - 若 A 包写
"monolog/monolog": "^1.25"，B 包写"monolog/monolog": "~2.9.0"，它们无交集——~2.9.0最多到2.9.9，而^1.25死守1.x - 写宽松前，务必去 Packagist 查对方是否真做语义化发布；很多包标着
v2.0.0却在小版本里破坏 API，这时^2.0就是坑
真正难的不是命令怎么敲，而是读懂 why-not 输出里每一行的约束来源，以及判断哪个包的版本约束是你能改、该改、改了也不破功能的——这需要你同时看懂自己代码、上游包文档、Packagist 发布记录三样东西。
