直接结论：不删 vendor、不删 composer.lock，用 composer why-not 定位阻断链，再用 composer update vendor/package --with-dependencies 精准更新。
直接结论：不删 vendor、不删 composer.lock，用 composer why-not 定位阻断链，再用 composer update vendor/package --with-dependencies 精准更新。
为什么不能删 vendor 或 composer.lock
删了只是让 Composer 重跑一遍失败逻辑，大概率还是卡在同一个地方。更糟的是，composer.lock 里记录着当前实际生效的版本组合，它是你项目“此刻能跑起来”的唯一凭证。盲目清空等于主动放弃已验证的稳定状态。
- 报错不是包坏了，是某条依赖路径上出现了互斥约束（比如 A 要
guzzlehttp/guzzle:^7.0，B 要^8.0） -
composer.lock被删后，Composer 会按composer.json重新求解——而那个求解过程本就失败过一次 - 如果项目有 CI/CD，
composer.lock缺失会导致构建环境和本地不一致，稳定性反而下降
composer why-not vendor/package:version 怎么用
这是唯一能直击冲突源头的命令。它不看缓存、不依赖锁文件，而是从 Packagist 元数据里实时反查“谁在拦着这个版本”。输出是一条从下往上的阻断链，最后一行是你 composer.json 里的根声明，往上第一处带 (required by) 的就是冲突源头。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须写完整版本号，例如
composer why-not laravel/framework:11.0.0，写11或^11可能返回空 - 如果输出为空，先检查
require-dev——很多冲突来自phpunit/phpunit或mockery/mockery拖着老版sebastian/exporter，间接锁死symfony/console - 遇到
Root package requires php: "7.4"这类提示，说明你composer.json里写的 PHP 版本太窄，而新包已放弃支持
如何安全更新一个冲突包
目标是只动目标包及其直系依赖，不动其他。全量 composer update 容易触发 SAT 求解器卡死，尤其在依赖多的项目里。
- 正确写法：
composer update monolog/monolog --with-dependencies—— 它只更新该包 + 它明确 require 的子依赖 - 错误写法：
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，确认只有目标包及其直系依赖被改，没波及其他
容易被忽略的隐性冲突点
很多冲突根本不在 require 字段里，而是藏在 require-dev、autoload 或 conflict 字段中。
-
conflict是硬规则，不是提醒。比如某个私有 SDK 声明"conflict": {"laravel/framework": ">=11.0"}，哪怕你没装 L11，只要其他已装包间接拉进来，就会触发冲突 -
autoload可能造成隐式循环：比如phpunit/phpunit的autoload把你的src/加进加载路径，而你的代码又继承它的TestCase，运行时形成闭环 - 镜像源没配对成功也会伪装成依赖冲突。验证方式：
composer config -g repo.packagist必须输出完整 URL；composer show packagist/support的source.url必须含mirrors.aliyun.com
真正难的不是操作步骤，而是读懂 composer why-not 输出里那条阻断链——它不会告诉你“该删哪个包”，只会指出“谁提了什么要求”。你需要顺着箭头一层层看，直到找到那个你可控的、能改的节点。
