Composer语义化版本冲突本质是多个依赖约束无数学交集，须先用composer why-not定位阻塞链并倒读输出，再通过composer why追溯路径，优先调整私有包或require-dev约束，慎用--with-dependencies等命令。
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)<br>laravel/sanctum ^3.0 requires guzzlehttp/guzzle (^7.2)
这就锁定了冲突源头是 guzzlehttp/guzzle。注意：必须从最后一行（通常是你的根项目）倒着读，才能看清谁最先提出不可让步的要求。
- 如果输出为空或只有
nothing，说明你要装的版本根本没发布过，不是冲突，是版本不存在 -
composer why查的是“已安装版本”的依赖路径；why-not才是你还没装成功时的第一工具 - require-dev 中的包（比如
phpunit/phpunit或orchestra/testbench）经常悄悄拉入旧版依赖，它们参与解析，不能忽略
^1.2.3 和 ~1.2.3 的差异真会影响能否解出依赖
这不是写法风格问题，是范围定义不同，直接决定有没有交集：
-
^1.2.3等价于>=1.2.3 ，允许所有 1.x 小版本和补丁 -
~1.2.3等价于>=1.2.3 ，只允许补丁级更新 - 一个包写
"monolog/monolog": "^2.0"，另一个写"monolog/monolog": "~1.25"，它们的语义范围没有重叠，Composer 就无法选版本
查 Packagist 页面，看哪个具体版本（比如 2.9.3）能同时被两个约束接受，再手动指定它："monolog/monolog": "2.9.3"，然后跑 composer update monolog/monolog 单点更新。
branch-alias 只对已声明的包有效，别自己瞎加
某些包（如 Laravel、Symfony 生态里的）在 composer.json 的 "extra": {"branch-alias": {...}} 中声明了别名，例如把 dev-main 映射成 3.0.x-dev，这样 require "vendor/package": "^3.0" 才能匹配上开发分支。
- 运行
composer show vendor/package可确认该包是否启用了别名及映射关系 - 若对方没设 alias，你
require dev-main会被视为9999999-dev，无法满足^3.0 - 你自己在项目
composer.json里加branch-alias完全无效——它只在被依赖方的包定义中起作用
composer update --with-dependencies 不是强制安装，是定点重算
这个命令不是跳过校验，而是在最小影响范围内让 Composer 重新计算目标包及其直系依赖的版本组合：
- 必须显式写包名，不带
^、~或引号：composer update monolog/monolog --with-dependencies - 加
--with-dependencies是关键，否则 Composer 常直接拒绝执行 - 升级后立刻
git diff composer.lock，确认只有该包和其直系依赖被改——多改一个symfony/polyfill-*都可能埋下运行时隐患 - 别删
composer.lock，它是当前已验证可行的依赖快照；删了等于扔掉唯一线索
真正难解的冲突，往往藏在私有包的 conflict 字段里——它全局生效，哪怕你没直接 require 那个包，只要间接拉进来就会触发。这种隐性约束，最容易被忽略。
