Composer update报冲突是因为它默认丢弃composer.lock、重新运行SAT求解器，一旦生态中出现不兼容新版本（如monolog/monolog 3.0.0）即暴露冲突；可用--with参数轻量验证兼容性，私有源需设"canonical": false防假冲突，锁文件合并冲突应执行composer update --lock而非手动修改。
composer update 时为什么突然报冲突？
不是你改了什么，而是 composer update 默认会重新求解整个依赖树——哪怕只改了一行 composer.json，它也会丢弃 composer.lock 中的旧决策，从头跑一遍 SAT 求解器。一旦生态里有新版本发布（比如 monolog/monolog 推了 3.0.0），而你的某个依赖还没适配，冲突就立刻暴露。
用 --with 参数临时验证兼容性，不碰锁文件
当你怀疑某个包其实能升级，但又不敢全量 update，--with 是最轻量的验证手段：
-
composer update --with=monolog/monolog:^3.0：强制让求解器把monolog/monolog纳入候选，其他包仍按锁文件版本约束参与求解 - 它不会修改现有
composer.lock，也不会更新其他包，失败了也无副作用 - 成功后，再执行
composer update monolog/monolog才真正落锁
私有仓库配置错导致“假冲突”
你以为是版本冲突，其实是 Composer 根本没查到 Packagist 上的正确版本——因为私有源默认开启 "canonical": true，只要同名包存在，就直接终止后续查找。结果就是：
- 私有源里只有
myorg/utils，但声明了"url": "https://my-priv.repo"且没设"canonical": false - Composer 查
monolog/monolog时，在私有源返回 404 后直接报错，根本不去 Packagist 查^2.10 - 解决方案：在
repositories数组里每个私有源都显式加"canonical": false
锁文件合并冲突后别手动改
Git 合并分支时 composer.lock 出现 composer install —— 这会导致依赖树断裂。正确做法是：
- 先还原
composer.lock到任一分支的干净状态 - 运行
composer update --lock：它会忽略当前 lock 内容，仅根据composer.json重生成合法锁文件 - 如果提示 “package X is not present in the lock file”，说明
composer.json里写了但没被解析到，要检查是否拼写错误或仓库不可达
真正难处理的从来不是冲突本身，而是求解器在传播规则时对间接依赖的隐式约束——比如 A 包要求 B ≥2.0，B 包又悄悄依赖 C 的某个 dev 分支，而 C 的稳定版根本不满足那个分支的 API。这种链式约束不会直接写在 composer.json 里，只能靠 composer why 和 composer show 一层层剥开看。
