Composer依赖冲突本质是多个组件对同一依赖提出无交集的语义化版本约束，需先用composer why-not定位阻断链（从root requires倒推），重点排查require-dev中的隐式约束，优先调整私有包版本而非主项目。
Composer模块化架构下的依赖冲突，不是“装不上”，而是多个组件对同一依赖提出了无法共存的语义化版本约束——它已经穷举过所有组合，没交集，就直接放弃。
composer why-not 是你第一个该敲的命令
报错里只写 Conclusion: don't install laravel/sanctum:^3.0，但没说谁在拦。这时候别改 composer.json，先问 Composer：composer why-not laravel/sanctum:^3.0。
它输出的是反向阻断链，得从最后一行（root requires）倒着读：
- 最后一行是你自己的
myapp/myproject dev-main在require某个旧版 - 中间行可能是私有 SDK、测试工具，或
require-dev里的包悄悄锁死了依赖 - 看到某行带
conflict with foo/bar (>=2.0)，别急着怪foo/bar——那是它自己声明的硬规则，Composer 只是照办
常见误操作：composer depends 查“谁在用它”，但你要的是“谁不让它进来”，必须用 why-not。
require-dev 是模块化项目中最常被忽略的冲突源
主项目用 laravel/framework: ^10.0，却让 orchestra/testbench: ^7.0 进来——它内部硬绑 Laravel 9，冲突立刻触发。这类问题在模块化开发中高频出现，因为每个组件都可能自带一套 require-dev。
验证方式：composer show --tree | grep -A2 -B2 "symfony/console"，看是不是某个测试工具把 symfony/console 卡死在 5.x。
-
phpunit/phpunit常悄悄拉进不兼容的symfony/console或guzzlehttp/guzzle - 私有包的
composer.json里写了"minimum-stability": "dev"，但没配"prefer-stable": true，导致dev-main被当作稳定依赖参与解析 - 删掉
require-dev后再试composer update --dry-run，如果冲突消失，就坐实是它的问题
改版本不是调数字，是找语义化交集
冲突本质是约束无重叠，比如一个写 "monolog/monolog": "^1.25"，另一个写 "monolog/monolog": "^2.10"——它们之间没有交集。
可行操作：
- 去 Packagist 查发布记录，找一个同时被双方接受的版本（如
v2.9.3既满足^2.0又满足>=2.8.0） - 把宽泛约束改成具体版本：
"monolog/monolog": "2.9.3"，再跑composer update monolog/monolog - 用逻辑或放宽：
"monolog/monolog": "^1.25 || ^2.10"——但前提是你的代码真能同时跑通两套 API，否则只是把问题拖到运行时报错 - 优先改私有包的
composer.json，而不是主项目；模块化开发中，上游组件才是约束源头
composer update 卡住超过 2 分钟？那不是网络慢
那是 SAT 求解器在暴力回溯，尤其当项目有 conflict、replace 或 30+ 包时，复杂度指数上升。
正确应对：
- 先跑
composer update --dry-run -v，看日志里是否高频出现Trying+ 回退，确认是解析瓶颈 - 用
composer update vendorA/pkgA vendorB/pkgB --with-dependencies，缩小搜索空间，每次只动一两个关键路径 - 避免
composer update全量重算；更别删composer.lock或vendor/——那是现场证据，不是病灶 - 升级后立刻
git diff composer.lock，确认只有预期变更；多改一个symfony/polyfill-*都可能埋下运行时隐患
最易被忽略的一点：很多冲突根本不在业务代码里，而在 require-dev 的测试工具链中——它们不参与运行，却全程参与依赖解析。
