“Your requirements could not be resolved”表示依赖约束无解，需用composer update --dry-run -v、why-not、show --tree等命令精准定位冲突源，而非删除vendor或lock文件。
看到 “Your requirements could not be resolved” 别删 vendor
这句报错不是 Composer 卡住了，而是它明确告诉你：当前 composer.json 里所有依赖约束加起来，在整个 Packagist 生态中**根本不存在一个能同时满足的版本组合**。删 vendor 或 composer.lock 不仅不解决问题，反而会掩盖真实冲突点——比如 lock 文件里早有不一致，但被“重装”绕过去了。
- 立刻执行
composer update --dry-run -v，看详细回溯过程里哪个包把某个依赖“焊死”在某个版本（重点盯but that version is not installable because后面的内容） - 如果报错涉及 PHP 版本或扩展（如
ext-gd），马上跑composer show --platform确认本地环境是否真不匹配 - 别信“我刚装好 Laravel 9，加个新包就崩”，往往是因为
require-dev里的phpunit/phpunit悄悄拉进了symfony/console:^7.0，而主框架只认^6.4
用 composer why-not 直接揪出拦路者
composer why-not 是最接近真相的命令。它不猜、不绕，直接列出所有阻止你安装某个版本的“反对票”。比如你想装 laravel/framework:10.40.0 失败了，就运行：
composer why-not laravel/framework:10.40.0
输出可能类似：
myapp/myproject requires laravel/framework (^9.0) spatie/laravel-backup requires laravel/framework (^10.0)
这时你就知道：不是 Laravel 本身有问题，而是你的根项目没升级，成了硬性天花板。
- 如果
why-not返回空，说明没有包显式要求那个版本——可能是conflict字段、replace声明，或某个dev分支的宽松约束在起作用 - 别对
why-not的结果做“字面理解”，比如它说your-project requires ^9.0，你要检查的其实是composer.json里是不是还写着"laravel/framework": "^9.0"，而不是去改 Laravel 的源码 - 注意区分
composer why和composer why-not：why只回答“谁用了这个包”，why-not才回答“谁不让它用这个版本”
查依赖树时优先看 composer show --tree 而非瞎猜
composer show --tree 输出的是当前 composer.lock 中已解析成功的依赖结构，它不反映冲突，但能帮你验证“某个包实际被哪个上游拉入”。真正排查冲突要先让 Composer 失败，再用诊断命令定位。
- 运行
composer show --tree | grep "symfony/console"，看是否多个路径引入了不同版本（比如一条来自laravel/framework，另一条来自phpunit/phpunit） - 如果发现冲突包被
require-dev中的包层层引入，而你只在生产环境部署，可以考虑用--no-dev安装，或把 dev 包移到config.platform下临时压制 - 某些包会用
"replace": {"symfony/console": "*"}声明自己“替代”某个依赖，这种声明默认不参与冲突检测，除非你显式启用——但它确实会影响解析逻辑，值得在composer.json里搜一搜
更新包时慎用 composer update vendor/package
这个命令默认只更新目标包及其直接 require 的依赖，不碰其他树分支。结果常是：你升了 A 包，它带进来的 B 包版本却和 C 包冲突，而 C 包原地不动，冲突照旧。
- 想真正对齐生态，用
composer update vendor/package --with-all-dependencies，让 Composer 重新推演整棵树 - 更稳妥的做法是分两步：
composer require symfony/http-kernel:^5.4 --no-update先改composer.json，再composer update symfony/http-kernel --with-all-dependencies - 如果只是加一个新包且怕连锁反应，加
--with-all-dependencies反而更干净；但如果项目已上线，千万别在生产环境直接跑，它可能把guzzlehttp/guzzle从 7.x 升到 8.x，导致new GuzzleHttp\Client()运行时报错
复杂点在于：很多冲突不是单点问题，而是多个间接依赖之间形成的“环状约束”。比如 A 要 X^1.0，B 要 X^2.0，C 又通过 D 依赖了 A 和 B —— 这时候光调一个包没用，得看谁才是那个真正卡死交集的“中间人”。
