Composer版本冲突是SAT求解器穷举后确认无解的数学结论，必须先用composer why-not定位阻塞链（从输出最后一行倒推），再结合composer show --tree查依赖树，优先调整私有包或require-dev中的约束，而非盲目修改主项目composer.json。
Composer 提示版本冲突，代表它已经穷举过所有可能的包版本组合，但找不到一组能同时满足 composer.json、composer.lock、PHP 平台配置、conflict 字段以及 require-dev 中所有约束的解——这不是临时卡顿或网络问题，是数学意义上的无解。
为什么 composer why-not 是必须第一步
报错里写的 Conclusion: don't install laravel/sanctum:^3.0 只是结果，不是原因。真正拦住它的，可能是你没直接 require 的某个测试工具，或者私有 SDK 里写死的 guzzlehttp/guzzle ^6.5。
- 运行
composer why-not laravel/sanctum:^3.0，从输出最后一行（通常是你的根项目）开始倒着读，每一行末尾的(required by xxx)是向上追溯的起点 - 如果某行末尾是
conflict with vendor/pkg (>=2.0)，说明那个包自己声明了硬性互斥，不是 Composer 主动拦你 - 输出为空？那大概率是该版本根本不在 Packagist 上，别再试了
- 别用
composer depends替代——它只告诉你“谁在用”，不解释“为什么不能升”
composer update --with-dependencies 为什么比 composer update 更可靠
默认 composer update vendor/package 不会更新它的子依赖，而新版往往依赖更高版本的 psr/log 或要求 PHP >=8.1 —— 这些旧值还锁在 composer.lock 里，导致命令直接拒绝执行。
- 必须加
--with-dependencies：它让 Composer 同时重算目标包及其直系依赖的最小可行集，比如升级monolog/monolog时顺带升级它要的psr/log - 别写
composer update "monolog/monolog:^3"：引号 +^会让 Composer 去找“最新兼容版”，而不是你心里想的那个 3.0.0 - 升级后立刻
git diff composer.lock，确认只有目标包和它的直系依赖被改；多改一个symfony/polyfill-*都可能埋下运行时隐患
PHP 版本不匹配时别碰 --ignore-platform-reqs
报错 requires php ^8.1 but your php version is 7.4.33 是明确拒绝，不是警告。绕过它只会把问题拖到 autoload 失败或类方法不存在。
- 先确认 CLI 环境真实版本：
php -v，再查composer config platform.php是否一致；Linux/macOS 可用/usr/bin/php8.1 composer install指定解释器 - 如果无法升级 PHP，就锁定兼容旧版：比如把
"laravel/framework": "^10.0"改成"laravel/framework": "^9.52"（Laravel 9 最后支持 PHP 7.3+） -
--ignore-platform-reqs对语义化版本冲突完全无效，它只是关掉校验开关，不解决底层不兼容
最常被忽略的一点：冲突往往藏在 require-dev 里。比如 phpunit/phpunit 和主框架都依赖 sebastian/exporter，但一个要 v5，一个要 v6——这种间接拉入的约束，不跑 composer why-not 根本看不见。
