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接着查谁把它锁死在^6.5—— 常见来源是私有 SDK、require-dev里的phpunit/phpunit或测试工具 - 注意：
composer depends查“谁用了它”，composer why才查“为什么它被拉进来”；composer prohibits才查“谁不让装这个版本”
锁定版本不是调数字，而是找语义化交集
冲突本质是多个约束没重叠，比如一个写 "monolog/monolog": "^1.25"，另一个写 "monolog/monolog": "^2.10"，它们之间没有交集。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 去 Packagist 查哪个版本同时被两个依赖接受（例如
monolog/monolog 2.9.3可能被 A 的^2.0和 B 的>=2.8.0同时接受） - 把宽泛约束改成具体版本：
"monolog/monolog": "2.9.3"，再跑composer update monolog/monolog单点更新 - 若必须兼容两套 API，可写
"monolog/monolog": "^1.25 || ^2.10"，但前提是你的代码真能同时跑通——否则只是把问题拖到运行时报错 - 别在
require-dev里塞和主项目冲突的包，比如主项目用laravel/framework: ^10.0，就别让orchestra/testbench: ^7.0进来，它内部硬绑 Laravel 9
--with-all-dependencies 不是跳过冲突，而是重算整棵树
这个参数的真实作用是让 Composer 主动升级/降级已有包来满足新约束，适合你明确信任新包、且接受关联变更的场景。
-
composer require laravel/sanctum --with-all-dependencies可能把guzzlehttp/guzzle从 6.x 升到 7.x，也可能把symfony/http-foundation从 v5 升到 v6 - 副作用明显：主版本跃迁可能破坏
new GuzzleHttp\Client()等调用；团队协作时必须提交更新后的composer.lock，否则别人composer install会失败 - 它不适用于生产环境紧急修复——改的是整棵树，不是单点；卡在
Resolving dependencies超过 5 分钟？那不是网络慢，是 SAT 求解器在暴力试错 - 更可控的做法是：
composer update vendorA/pkgA vendorB/pkgB --with-dependencies，每次只动一两个关键路径
重建依赖树前，先确认是不是 lock 文件或 conflict 字段在捣鬼
composer install 报 conflict，往往不是约束逻辑问题，而是 composer.lock 和当前 composer.json 不匹配，或某个包的 conflict 字段全局生效。
- Git 拉了别人提交的新
require，但没同步lock文件？执行composer update --lock或直接删composer.lock再composer install - 有些包在自己的
composer.json里写了"conflict": {"laravel/framework": ">=11.0"}，哪怕你项目没装 L11，只要其他依赖把它间接拉进来，Composer 就会全局拒绝 - 极端情况可临时加
"prefer-stable": true到composer.json，压制 dev 分支干扰（某些包的 dev 分支会声明宽松约束） - 别急着删
vendor/和composer.lock—— 那是掩盖问题，不是解决；先composer show --tree | grep guzzle确认它是不是被require-dev里的某个工具悄悄拉进来的
