Composer版本冲突本质是多个组件对同一依赖提出无交集的语义化版本约束，需先用composer why-not定位阻塞链，再通过composer why追溯依赖路径，优先调整私有包或require-dev中的约束，而非盲目修改主项目composer.json。
Composer 模块化开发中出现版本冲突，不是“装不上某个包”，而是多个组件对同一依赖提出了无法共存的语义化版本约束——它已经穷举过所有组合，没交集，就直接放弃。
composer why-not 是你第一个该敲的命令
报错里只写 Conclusion: don't install laravel/sanctum:^3.0，但没说谁在拦。这时候别改 composer.json，先问 Composer：
composer why-not laravel/sanctum:^3.0
它会输出真实阻塞链，例如：
myapp/myproject dev-main requires guzzlehttp/guzzle (^6.5)laravel/sanctum ^3.0 requires guzzlehttp/guzzle (^7.2)
这说明冲突不在 sanctum 本身，而在 guzzlehttp/guzzle 的版本范围无交集。接着顺藤摸瓜：
composer why guzzlehttp/guzzle
常见结果是某个私有 SDK、老旧测试工具，或 require-dev 里的包锁死了 6.x。
容易踩的坑：
- 用
composer depends替代why——depends查“谁依赖它”，why才查“为什么它被装进来” - 忽略
require-dev里的隐式拉取：比如phpunit/phpunit可能悄悄带进不兼容的symfony/console - 看到报错末尾的
found x packages...就动手删vendor—— 那只是结论，不是根因
改 composer.json 不是调数字，而是找语义化交集
冲突本质是多个约束没重叠，比如一个写 "monolog/monolog": "^1.25"，另一个写 "monolog/monolog": "^2.10"。它们之间没有语义化版本交集，Composer 就没法选。
可行操作包括：
- 去 Packagist 看哪个版本同时被两个依赖接受（比如
monolog/monolog 2.9.3可能被 A 的^2.0和 B 的>=2.8.0同时接受） - 把宽泛约束改成具体版本：
"monolog/monolog": "2.9.3"，再跑composer update monolog/monolog单点更新 - 用逻辑或放宽：
"monolog/monolog": "^1.25 || ^2.10"—— 但前提是你的代码真能同时跑通两套 API，否则只是把问题拖到运行时报错
如果冲突来自你控制的私有包，优先改它的 composer.json，而不是主项目。
模块化开发中 require-dev 是隐形雷区
主项目用 laravel/framework: ^10.0，却让 orchestra/testbench: ^7.0 进来 —— 它内部硬绑 Laravel 9，就会触发冲突。这类问题在模块化开发中尤其高频，因为每个组件都可能自带一套 require-dev。
检查方式：
-
composer show --tree | grep -A5 -B5 guzzlehttp/guzzle看是不是被某个dev包悄悄拉入 -
composer prohibits guzzlehttp/guzzle:7.5.0查谁明确拒绝这个版本 - CI 脚本中运行前加
php -v和composer config platform.php，确认三者一致
临时绕过可用 composer update --dry-run --verbose 看完整决策路径，但别提交 --ignore-platform-reqs 到生产环境。
composer update --with-dependencies 不是万能钥匙
这个参数不是“跳过冲突”，而是让 Composer 重算局部依赖树，主动升级/降级已有包来满足新约束。适合你明确信任新包、且接受关联变更的场景。
例如：
composer update laravel/sanctum --with-dependencies
它可能把 guzzlehttp/guzzle 从 6.x 升到 7.x，也可能把 symfony/http-foundation 从 v5 升到 v6。
但要注意：
- 别对整个生态用
--with-all-dependencies，尤其当项目有conflict或 30+ 包时，SAT 求解器复杂度指数上升，Resolving dependencies卡住 5 分钟以上就是信号 - 每次只动一两个关键路径，用
composer update vendorA/pkgA vendorB/pkgB --with-dependencies缩小搜索空间 - 升级后立刻
git diff composer.lock，确认只有预期的包和其直系依赖被改动
模块化开发最易被忽略的一点：组件间版本约束的“隐性耦合”往往藏在 require-dev 和 conflict 字段里，而不是主 require —— 它们不会出现在生产环境，但会彻底堵死依赖解析路径。
