应使用composer why-not定位阻断目标版本的依赖，再通过composer update --with-dependencies精准更新，而非删除vendor或composer.lock。
直接告诉你：别删 vendor 或 composer.lock，那只是重跑一遍失败逻辑；真正该做的，是用 composer why-not 定位谁在封杀目标版本，再配合 composer update --with-dependencies 精准调整。
用 composer why-not 找出真实拦路虎
报错里写 don't install laravel/framework:11.0.0，不代表它本身有问题——那是结果，不是原因。运行：
composer why-not laravel/framework:11.0.0
输出是一条反向阻断链，要从最后一行倒着读：
- 最后一行是你
composer.json里的根声明（比如myapp dev-main requires laravel/framework:^11.0） - 往上每一行末尾的
(required by ...)是向上追溯的起点 - 看到某行写
package-a v2.1 requires guzzlehttp/guzzle ^7.0，而另一行是package-b v3.0 requires guzzlehttp/guzzle ^8.0，冲突点就落在guzzlehttp/guzzle上 - 如果输出为空，说明问题可能出在
require-dev里（比如phpunit/phpunit拖着旧版symfony/console）
用 composer update 精准更新，不碰无关包
全量 composer update 容易触发 SAT 求解器卡死，尤其项目依赖多时。升级单个包必须加 --with-dependencies：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer update monolog/monolog --with-dependencies
不加这个参数，Composer 默认拒绝更新其子依赖，哪怕新版本根本跑不起来。注意：
- 别写
composer update "monolog/monolog:^3"—— 引号 +^会让它找“最新兼容版”，不是你要的3.0.0 - 降级跨主版本（如从
^8.0切回7.4.5），必须在composer.json里写死："guzzlehttp/guzzle": "7.4.5"，不能只写"^7.0" - 执行后立刻
git diff composer.lock，确认只有目标包及其直系依赖被改
查真实依赖结构，别信“理想状态”
composer show --tree 显示的是 vendor/ 和 composer.lock 的真实快照，不是你 composer.json 里写的“愿望清单”。它能暴露你根本没意识到的间接路径：
- 运行
composer show --tree | grep "symfony/console"，看它被几个路径引入、是否带(locked to 5.4.42) - 如果某包显示
(replaced)或(provided)，得去它composer.json里确认是否真能等价 - 树太深？用
composer show --tree monolog/monolog | grep -A5 -B5 "guzzlehttp/guzzle"过滤关键段 -
composer show --tree在 Composer 2.5+ 已被移除，若命令不存在，改用composer show --format=tree
生产环境锁文件失效，只用 composer update --lock
线上报 Your requirements could not be resolved，大概率是 composer.lock 和 composer.json 脱节，或 CI 构建时用了 --ignore-platform-reqs。此时绝不能删 vendor 或手动改 lock：
- 运行
composer update --lock—— 它只按当前composer.json重建合法锁文件，不动vendor/ - 预期输出是
Lock file operations: 0 installs, 0 updates, 0 removals；如果出现大量Updating xxx，说明composer.json还没对齐，得先拉代码 - 生成新
composer.lock后，立刻git add composer.lock && git commit，确保下次部署可复现 - 切勿执行
rm -rf vendor/ && composer install—— 这会绕过所有版本契约，装入未测试过的组合
复杂点在于：冲突往往藏在第二、三层依赖里，且 require-dev 默认参与解析——很多人直到线上报错才意识到 phpunit/phpunit 正在悄悄卡死 symfony/console 版本。
