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)
这就锁定了冲突源头是 guzzlehttp/guzzle。再顺下去查谁在死守 6.x：
composer why guzzlehttp/guzzle
常见结果是某个私有 SDK、老旧测试工具或 require-dev 里的包（比如 phpunit/phpunit 拉进了不兼容的 symfony/console）。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用
composer depends查“谁依赖它”，composer why才查“为什么它被装进来” - 忽略
require-dev里的隐式拉取：比如主项目用laravel/framework: ^10.0，就别让orchestra/testbench: ^7.0进来——它内部硬绑 Laravel 9 - 看到报错末尾的
found x packages...就动手删vendor——那只是结论，不是根因
改 composer.json 不是调数字，而是找语义化交集
冲突本质是多个约束没重叠，比如一个写 "monolog/monolog": "^1.25"，另一个写 "monolog/monolog": "^2.10"。它们之间没有语义化版本交集，Composer 就没法选。
- 查 Packagist，看哪个版本同时被两个依赖接受（比如
monolog/monolog2.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，而不是主项目
branch-alias 只对已声明的包有效，别自己瞎加
某些包（尤其是 Symfony、Laravel 生态里的）在开发分支中通过 branch-alias 声明了语义化别名，例如把 dev-main 映射成 3.0.x-dev。当你 require 一个尚未发正式版但已有兼容实现的分支时，这个别名能让 Composer 认为它满足 ^3.0 的约束。
- 只对已明确声明
branch-alias的包有效（查其composer.json的"extra": {"branch-alias": {}}） - 别自己瞎加
branch-alias到自己项目里——它只在被依赖方的包定义中起作用 - 运行
composer show vendor/package可看到是否启用了别名及映射关系 - 若对方没设 alias，
require dev-main仍会被视为9999999-dev，无法匹配^3.0
composer update --with-dependencies 比 --with-all-dependencies 更可控
--with-all-dependencies 是全局重算，风险高；--with-dependencies 是定点升级，只影响目标包及其子依赖树。
- 必须显式写包名，不能带
^或引号，例如composer update monolog/monolog --with-dependencies - 如果失败，说明该包的子依赖链里仍有硬冲突，此时再跑一次
composer why-not查新暴露出来的包 - 升级后立刻检查
git diff composer.lock，确认只有预期变更——多改一个symfony/polyfill-*都可能埋下运行时隐患 -
--ignore-platform-reqs对真正的语义化版本冲突（如^1.0vs^2.0）完全无效，只会把问题拖到 autoload 失败或类方法不存在
最常被忽略的是：冲突往往藏在 require-dev 里，而 composer why 默认只查已安装项。如果目标包还没装成功，why-not 才是你唯一可靠的起点。
