核心是暴露阻塞点并最小干预：用composer why-not定位封杀链，composer show --tree查看真实依赖结构，升级单个包必须加--with-dependencies，避免盲目删vendor或全量update。
Composer处理共享依赖版本冲突，核心不是“绕过”或“强制覆盖”，而是让求解器看清约束本质、暴露真实阻塞点，再做最小干预。盲目删vendor或跑composer update只会重复失败。
用 composer why-not 找出谁在封杀目标版本
报错里出现don't install symfony/console:^6.0，别猜是哪个包拦路——直接查：
- 必须带完整版本号：
composer why-not symfony/console:^6.0.0（写^6.0可能匹配不到元数据） - 输出是反向链：最后一行是你
composer.json里的声明，往上逐行看哪条required by提出了互斥约束，那就是源头 - 输出为空？先检查
require-dev——很多冲突来自phpunit/phpunit拖着老版sebastian/exporter，间接锁死symfony/console
composer show --tree 看清真实依赖结构
composer.json是你写的“愿望清单”，composer show --tree才是vendor/和composer.lock里的真实快照：
- 执行
composer show --tree monolog/monolog | grep -A5 -B5 "guzzlehttp/guzzle"，能定位间接路径 - 注意括号里的
(locked to 5.4.42)——说明该版本已被composer.lock固化，不是当前composer.json决定的 - 看到
(replaced)或(provided)，得去那个包自己的composer.json里确认它到底替代了什么、是否真能覆盖
升级单个包时必须加 --with-dependencies
不加这个参数，Composer默认拒绝更新其子依赖，哪怕新版本根本跑不起来：
- 正确写法：
composer update monolog/monolog --with-dependencies——只动它和直系依赖 - 错误写法：
composer update "monolog/monolog:^3"——会卡在旧子依赖上，无法推进 - 想轻量验证兼容性，用
composer update --with=monolog/monolog:^3.0：不改composer.lock，失败也无副作用
私有源配置错会导致“假冲突”
你以为是版本冲突，其实是 Composer 根本没查到 Packagist 上的正确版本：
- 私有源默认开启
"canonical": true，只要同名包存在，就直接终止后续查找 - 结果就是：私有源里只有
myorg/utils，但声明了"url": "https://my-priv.repo"且没设"canonical": false - Composer 查
monolog/monolog时，在私有源返回 404 后直接报错，根本不去 Packagist 查^2.10 - 解决方案：在
repositories数组里每个私有源都显式加"canonical": false
真正难处理的从来不是版本号本身，而是某个replace声明没覆盖全、某个require-dev包悄悄锁死了主干依赖、或者composer.lock里残留着早已被移除的包的锁定记录——这些细节不会出现在报错第一行，但会反复让你在同一个坑里栽三次。
