composer why-not 是定位依赖冲突根源的关键命令，它从根项目逆推输出阻塞链，揭示私有SDK等高频冲突源，而非仅显示最终不兼容结论。
composer why-not 为什么必须第一个跑
报错里那句 Conclusion: don't install laravel/sanctum:^3.0 只是结果，不是原因。Composer 不会告诉你谁在拦，只告诉你“拦住了”。composer why-not laravel/sanctum:^3.0 才是真正打开黑盒的钥匙——它输出的是阻塞链，从根项目倒推到最底层冲突点。
常见误操作：
- 看到
conflict with guzzlehttp/guzzle (>=7.0)就去删 Guzzle，其实那是被拦包自己声明的约束，不是拦它的元凶 - 把
composer why-not输出从上往下读，而正确顺序是从最后一行（你的composer.json）往上逆推 - 忽略括号里的
(required by myapp/sdk v2.1)—— 私有 SDK、内部组件才是高频冲突源，不是公开包
^ 和 ~ 的语义交集到底怎么算
^1.25.0 等价于 >=1.25.0 ，<code>~2.8.0 等价于 >=2.8.0 。两者无交集，Composer 就不可能选一个版本同时满足它们。这不是“不够聪明”，是数学上无解。
实操要点：
- 用 Packagist 查目标包所有可用版本，找一个落在两个范围重叠区的版本（比如
monolog/monolog:2.9.3同时满足^2.0和>=2.8.0） - 别写
"monolog/monolog": "^1.25 || ^2.10"—— 这等于告诉 Composer “随便选”，但你的代码大概率只兼容其中一套 API -
!=2.3.0这种排除式约束会显著拖慢 SAT 求解器，因为要传播禁用变量，优先用^或~替代
composer update monolog/monolog --with-dependencies 怎么不波及其他包
默认 composer update 是全局重算，哪怕你只改一行 composer.json，也可能把 laravel/framework 从 v10.32 升到 v10.33，顺带把 symfony/console 也卷进去。而 --with-dependencies 是唯一能控制影响半径的开关。
关键细节：
- 必须写成
composer update monolog/monolog --with-dependencies，不能加引号或^符号，否则 Composer 会当成模糊匹配去搜最新版 - 升级后立刻
git diff composer.lock，确认只有monolog/monolog和它的直系依赖（如psr/log）被改动 - 如果提示 PHP 版本不满足（比如
monolog/monolog:3.0.0要PHP >=8.1），说明环境不匹配，不是命令问题
dev-main 被锁死时为什么 composer update 不动它
当你在 composer.json 里写 "some/package": "dev-main"，Composer 默认把它当不稳定分支处理；但如果另一个包要求 "some/package": "^1.0"，而 dev-main 没打正式 tag，SAT 求解器就无法将其映射到语义化版本空间，直接判为无解。
绕过方式有限且需谨慎：
- 确认该包是否真需要
dev-main—— 多数情况是开发调试用，上线应切回稳定版 - 若必须用，检查它是否有
branch-alias声明（如"dev-main": "1.0.x-dev"），没有就别硬 require -
composer update --with-all-dependencies会强制重解整棵树，但代价是可能连带升级几十个包，风险远高于收益
最常被忽略的点：冲突往往不在你写的 require 里，而在 require-dev 中某个测试工具悄悄锁死了生产依赖的升级路径。查之前先 composer show --tree | grep -A3 -B3 "your-conflict-package"，比盲目调版本更省时间。
