依赖冲突源于composer.json约束互斥，非网络或缓存问题；应优先用composer why-not定位阻塞链，结合composer show --tree查看真实依赖结构，并升级/降级时加--with-dependencies。
依赖冲突不是缓存或网络问题，是 composer.json 里写的约束互相抵触——删 vendor 或重跑 composer install 只会让同样的失败重演一遍。
用 composer why-not 定位谁在拦路
报错里出现 don’t install xxx，别猜，直接查。命令必须带完整版本号，比如：
-
composer why-not guzzlehttp/guzzle:^8.0.0—— 写^8.0可能匹配不到元数据，得写成^8.0.0或8.0.0 - 输出是从底往上读的反向链：最后一行是你
composer.json的根声明，往上逐行看哪条(required by)提出了互斥约束，那就是冲突源头 - 输出为空？先检查
require-dev—— 很多冲突来自phpunit/phpunit或mockery/mockery拖着老版sebastian/exporter，间接锁死symfony/console - 加
--dry-run验证改动是否真能解出路径，例如composer require laravel/framework:11.0.0 --dry-run，不改任何文件就提前看到结果
用 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" - 过滤关键段：
composer show --tree monolog/monolog | grep -A5 -B5 "guzzlehttp/guzzle" - 看到
(provided)或(replaced)，得去那个包自己的composer.json里确认它到底替代了什么、是否真能覆盖 - 注意括号里的
(locked to 5.4.42)—— 这说明该版本已被composer.lock锁定，不是当前composer.json声明决定的
定点更新，别全量 composer update
全量 composer 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，确认只有目标包及其直系依赖被改，没波及其他
镜像源和缓存不是万能解药，但必须先配对再排查
中文镜像不能解决依赖冲突，只让冲突暴露得更快、更准。但它必须配对使用：
- 配置镜像后务必执行
composer clear-cache，否则旧缓存会干扰新源行为 - 检查
composer config -g repo.packagist是否指向有效镜像地址（如https://packagist.phpcomposer.com已停用，应换为https://mirrors.aliyun.com/composer/） - 如果项目用了私有
repositories，确保它们没和 Packagist 镜像冲突 —— 比如 VCS 仓库里写了"type": "vcs"却没指定"url"，会导致解析器跳过该源却仍计入约束范围 - 镜像只是加速元数据获取，不影响求解逻辑；真正卡在
Updating dependencies后面的报错，一律按约束冲突处理
最常被忽略的是 require-dev 里的隐性依赖链，以及 composer.lock 中已锁定但未显式声明的版本。动手改之前，先看树、再查阻塞、最后定点动，比反复清缓存有用得多。
