先运行composer why-not vendor/package:version定位阻塞链，再结合composer show --tree分析真实依赖结构，检查require-dev等隐形冲突源，并用--with-dependencies定点更新。
直接删 vendor 或 composer.lock 不解决冲突，只会让 Composer 重跑一遍失败逻辑；真正有效的动作是定位阻塞点、缩小求解范围、验证约束交集。
用 composer why-not 定位冲突源头
这是最可靠的第一步。报错里出现 don’t install xxx 时，别猜谁在拦路，直接问 Composer：
-
composer why-not guzzlehttp/guzzle:^8.0—— 输出是一条反向链，从最后一行（你composer.json的根声明）往上读，看到哪一行标着(required by)提出互斥约束，就是冲突起点 - 如果输出为空，先检查是否漏了
require-dev：很多冲突来自phpunit/phpunit或mockery/mockery拖着老版sebastian/exporter，间接锁死symfony/console - 必须用完整版本号，比如
laravel/framework:11.0.0，写成11或^11可能匹配不到元数据，返回空
用 composer show --tree 看真实依赖结构
composer.json 里写的只是“愿望清单”，composer show --tree 才反映 vendor/ 和 composer.lock 的真实快照：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer show --tree | grep "symfony/console"—— 查看它是否带(locked to 5.4.42)，确认实际装的是哪个版本 -
composer show --tree monolog/monolog | grep -A5 -B5 "guzzlehttp/guzzle"—— 过滤关键路径，看中间有没有某包标着(replaced)或(provided)，这类声明会影响依赖解析 - 注意
conflict字段是硬规则：哪怕你没require某个包，只要其他已装包间接拉进来，也会触发拒绝
定点更新比全量 composer update 更安全
全量 update 容易触发 SAT 求解器卡死，尤其依赖多的项目。升级单个包必须带 --with-dependencies：
- 正确写法：
composer update monolog/monolog --with-dependencies—— 只动它和直系依赖 - 错误写法：
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，确认只有目标包及其直系依赖被改，没波及其他
镜像、缓存、repositories 配置的隐形坑
中文镜像不能解决冲突，但能让冲突暴露得更快更准；90% 的“换源无效”其实是配置没生效：
- 验证镜像是否生效：
composer config -g repo.packagist输出应为完整 URL 字符串；composer show packagist/support的source.url应含mirrors.aliyun.com - 三个硬性条件缺一不可：命令末尾带
composer类型标识、URL 以/结尾、字段名是repo.packagist（不是repos.packagist） - 只要
composer.json里有"repositories"字段（哪怕空数组），全局镜像就会被丢弃——不是合并，是直接忽略 - 换镜像后仍拉
repo.packagist.org，90% 是缓存没清干净：composer clear-cache必须执行，Windows 用户还得手动删%LOCALAPPDATA%\Composer\cache
复杂点在于：冲突往往不是单点问题，而是多个约束在隐式路径上叠加形成的死锁；最容易被忽略的是 require-dev 中的 autoload 反向引用、私有包里的 conflict 全局生效、以及 composer.lock 里固化了过期的 provider 元数据。
