直接结论：别删 vendor 或 composer.lock，先跑 composer why-not 定位阻断链——90% 的冲突靠它 3 分钟内定位到根因；该命令输出反向依赖链，需从最后一行（根声明）倒序阅读，关键阻断点常在中间层包（如 spatie/laravel-backup），而非目标包本身。
直接结论：别删 vendor 或 composer.lock，先跑 composer why-not 定位阻断链——90% 的冲突靠它 3 分钟内定位到根因。
报错 “Your requirements could not be resolved” 是什么信号
这不是网络错误，也不是权限问题，是 Composer 在数学上证明：当前所有约束下无解。它不告诉你谁拦着，只告诉你“装不了”。常见诱因包括：
- 你刚合并分支，
composer.json里同时写了"laravel/framework": "^9.0"和"spatie/laravel-backup": "^7.0"，而后者尚未兼容 Laravel 9 - 某个包的
require-dev依赖（如phpunit/phpunit）锁死了symfony/console的旧版本，间接卡住主框架升级 - 本地 PHP 版本是 7.4，但你要装的包要求
php: >=8.1，错误信息里可能只写“don’t install xxx”，不提 PHP
composer why-not 怎么读才不绕晕
运行 composer why-not vendor/package:version（例如 composer why-not laravel/framework:11.0.0），输出是一条反向阻断链，必须从最后一行倒着看：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 最后一行是你
composer.json的根声明（如myapp dev-main requires laravel/framework:^11.0） - 往上每一行末尾的
(required by ...)是向上追溯的起点 - 真正卡死的包常在中间层，比如看到
spatie/laravel-backup v7.2.0 requires symfony/console ^5.4，而另一处又出现phpunit/phpunit v10.5.0 requires symfony/console ^6.0，冲突点就落在symfony/console - 如果输出为空，不是没冲突，而是该版本根本未发布（比如误输
^11.0而非laravel/framework:11.0.0），或包名/版本拼错
精准更新，避免全量重算导致新坑
全量 composer update 容易触发 SAT 求解器卡死，尤其依赖多时。升级单个包必须加 --with-dependencies：
- 正确写法：
composer update monolog/monolog --with-dependencies - 错误写法：
composer update "monolog/monolog:^3"—— 引号 +^会让 Composer 找“最新兼容版”，不是你要的 3.0.0 - 降级跨主版本（如从
guzzlehttp/guzzle ^8.0切回7.4.5），必须在composer.json里写死："guzzlehttp/guzzle": "7.4.5"，不能只写"^7.0" - 执行后立刻
git diff composer.lock，确认只有目标包及其直系依赖被改，其他路径不动
依赖树太深？用 composer show --tree 看真实快照
composer show --tree 展示的是 vendor/ 和 composer.lock 的真实快照，不是你 composer.json 里写的“愿望清单”。它能暴露你根本没意识到的间接路径：
- 查某包被谁引入：
composer show --tree | grep "symfony/console" - 过滤关键段：
composer show --tree monolog/monolog | grep -A5 -B5 "guzzlehttp/guzzle" - 看到某包标了
(replaced)或(provided)，得去它自己的composer.json里确认replace字段是否真能等价替代 - Composer 2.5+ 已移除
--tree，改用composer show --format=tree
复杂点在于：冲突常藏在第二、三层依赖里，而 composer.json 只管第一层。很多人盯着根声明改来改去，却漏掉 require-dev 里的 phpunit 正在拖后腿——这点最容易被忽略。
