真正卡住的是依赖图里某条隐性约束链，如spatie/laravel-backup硬绑laravel 10导致无法安装laravel 11；用composer why-not定位阻断源头，show --tree查看真实依赖树，精准update并验证lock变更。
别删 vendor 或 composer.lock —— 这不是解决，是重演失败。
为什么 composer install 报错“don’t install xxx”？
错误里写的“不装某个版本”，只是结果，不是原因。真正卡住的是依赖图里某条隐性约束链。比如你项目 require laravel/framework: ^11.0，但 spatie/laravel-backup 的当前版本只兼容 Laravel 10，它内部硬绑了 "laravel/framework": "^10.0"，这就形成反向封杀。
- 报错信息里出现的包名，大概率是“被拦住”的那个，不是“拦路”的那个
- 冲突常藏在
require-dev里（比如phpunit/phpunit拖着旧版symfony/console） -
composer.lock文件本身没问题，问题在于它忠实地记录了当前无法满足新需求的旧解
composer why-not 才是定位真凶的命令
运行它，才能看到谁在联合封杀目标版本：
composer why-not laravel/framework:11.0.0
输出是一条反向链，从下往上读：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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 ...)是阻断源头 - 看到两行都要求同一个包但版本互斥（比如一个要
guzzlehttp/guzzle ^7.0，另一个要^8.0），冲突点就在这里 - 如果输出为空，立刻检查
require-dev区块，或加--dev参数再试一次
用 composer update 精准更新，不是全量重算
全量 composer update 容易触发 SAT 求解器卡死，尤其依赖多时。升级必须带 --with-dependencies：
composer update spatie/laravel-backup --with-dependencies
- 不加这个参数，Composer 默认拒绝更新其子依赖，哪怕新版本根本跑不起来
- 别写
composer update "spatie/laravel-backup:^4.0"—— 引号 +^会让它找“最新兼容版”，不是你要的 4.0.0 - 降级跨主版本（如从
^4.0切回3.25.0），必须在composer.json里写死："spatie/laravel-backup": "3.25.0" - 执行后立刻
git diff composer.lock，确认只有目标包及其直系依赖被改
依赖树比 composer.json 更真实
composer show --tree 显示的是 vendor/ 和 composer.lock 的真实快照，不是你写的“愿望清单”。它能暴露你根本没意识到的间接路径：
- 查某个包被谁引入：
composer show --tree | grep "symfony/console" - 过滤关键段：
composer show --tree spatie/laravel-backup | grep -A5 -B5 "laravel/framework" - 看到某包标着
(replaced)或(provided)，得去它自己的composer.json里确认是否真能等价
复杂项目里，靠猜和删文件只会把问题拖得更久；真正耗时间的，是读清 why-not 输出的每一行、看懂 show --tree 里那个嵌套层级——那才是依赖关系的真实形状。
