Composer报错“Your requirements could not be resolved”表明依赖约束无解，应通过composer update --dry-run -v和composer why-not定位冲突源，而非删除vendor或lock文件。
看到 “Your requirements could not be resolved” 先别删 vendor
这句报错不是 Composer 在耍脾气，而是它明确告诉你：当前 composer.json 里写的依赖组合，在整个包生态中根本不存在一个能同时满足所有约束的版本解。删 vendor/ 或 composer.lock 不仅不能解决问题，反而会掩盖真实冲突点——尤其在 CI 环境里，可能让本该暴露的不兼容性被“重装”暂时绕过。
- 先运行
composer update --dry-run -v，看详细回溯过程里哪个包把某个依赖卡死在某个版本 - 重点盯住错误信息里反复出现的包名（比如
symfony/console）和它被多个路径引用的迹象 - 检查是否是某个
dev包（如phpunit、infection）悄悄拉进了生产环境不该有的高版本依赖
用 composer why-not 定位“谁在拦路”
composer why-not 是最快揪出冲突源头的命令。它不猜、不绕，直接列出所有阻止你安装目标版本的已存在依赖及其约束条件。
- 例如报错说装不上
laravel/framework:10.40.0，就立刻跑：composer why-not laravel/framework:10.40.0 - 输出里如果出现
your-project要求^9.0，而spatie/laravel-backup要求^10.0，那问题就清晰了：根项目没升级，但第三方包已要求新框架 - 注意看输出中有没有
conflict字段——有些包（如 Laravel 官方扩展）会显式声明与高版本互斥，这不是 bug，是设计如此
更新时别只敲 composer update vendor/package
这个命令默认只更新目标包及其直接 require 的依赖，不碰其他树分支。结果常是：你升了 A 包，它带进来的 B 包版本却和 C 包冲突，而 C 包原地不动，冲突照旧。
- 想真正对齐生态，用：
composer update vendor/package --with-all-dependencies - 如果只是加一个新包且怕连锁反应，加
--with-all-dependencies反而更干净，让 Composer 重新推演整棵树 - 更稳妥的做法是分两步：
composer require symfony/http-kernel:^5.4 --no-update先改composer.json，再composer update symfony/http-kernel --with-all-dependencies
放宽版本约束要“有依据”，不是乱加 ||
把 "monolog/monolog": "^1.25" 改成 "^1.25 || ^2.10" 看似解了冲突，但如果项目代码没适配 Monolog v2 的接口变更，运行时就会崩——这叫用构建期的妥协换 runtime 的灾难。
- 先查 Packagist，看哪些中间版本被上下游共同接受（比如
v2.9.3同时出现在 A 包的require和 B 包的conflict之外） - 确认兼容性后，优先锁具体小版本：
"monolog/monolog": "2.9.3"，比写范围更可控 - 避免用
*、dev-master或过宽的^1.0——它们不是灵活，是埋雷；主版本跳变（v5→v6）时，必须确认是否支持并行安装（如靠symfony/polyfill-*补丁）
真正的难点不在命令怎么敲，而在判断哪个包该升、哪个该锁、哪个其实可以砍掉。依赖图不是线性链条，而是一张网；改一处，得看清它连着哪几根线，哪根线另一头已经锈死了。
