Composer 不选版本而是强制统一为满足所有约束的最高兼容版本，通过 SAT 求解器实现依赖扁平化；冲突时可能降级，lock 文件中每个包仅存一份，但私有依赖视图可不同。
Composer 遇到菱形依赖时到底选哪个版本？
它不“选”，而是强制统一——只要所有路径指向同一个包，Composer 就会尝试找一个满足全部 require 约束的最高兼容版本。这个过程叫“依赖扁平化”，不是随机挑，也不是按声明顺序定，而是基于 SAT 求解器算出来的可行解。
常见错误现象：composer install 卡住、报 could not resolve packages，或升级后某个包突然行为异常（比如 monolog/monolog 从 2.x 降级到 1.x）。
- 你的项目直接 require
"guzzlehttp/guzzle": "^7.0" - 你用的
laravel/framework依赖"guzzlehttp/guzzle": "^6.5 || ^7.0" - 另一个包
spatie/laravel-backup要求"guzzlehttp/guzzle": "^6.2" - 最终 Composer 可能锁死在
6.5.5——因为这是唯一同时满足三方约束的版本
为什么 composer update 有时降级而不是升级？
因为新版本不一定满足所有路径的约束。Composer 的目标是“可安装”，不是“最新”。一旦某条依赖链只接受旧版，整个图就会被拉低。
使用场景：你在 CI 中跑 composer update，结果 phpunit/phpunit 从 10.x 回退到 9.x，测试开始报错。
- 检查具体冲突：运行
composer prohibits guzzlehttp/guzzle:7.0，看谁在拦着 - 别盲目加
--with-all-dependencies，它可能绕过约束导致隐性不兼容 - 想锁定升级方向？用
composer update guzzlehttp/guzzle --with-dependencies，只动它和直系依赖 - 注意
^和~的语义差异：^6.0允许 6.x 任意版，~6.2只允许 6.2.x
composer.lock 文件里为什么同一包出现多次？
不会。Composer 扁平化后，每个包在 lock 文件中只存一份，无论它被多少路径引用。但它的 require 字段可能列出多个不同版本的子依赖——那是它的“私有依赖视图”，不影响全局版本。
容易踩的坑：误以为 lock 文件里没重复就等于没冲突；其实冲突发生在解析阶段，lock 只是结果快照。
- 运行
composer show -t guzzlehttp/guzzle查看它被哪些包以什么约束引入 - 如果输出里出现
requires guzzlehttp/guzzle (6.5)和requires guzzlehttp/guzzle (7.2)并存，说明解析失败前就已冲突 -
lock文件中的content-hash改变，往往意味着依赖图结构变化，不只是版本浮动
手动干预菱形冲突的三个有效动作
别删 vendor 或硬改 lock。真正可控的是约束表达和解析边界。
- 收紧自己的
require：比如把"psr/log": "*"改成"psr/log": "^2.0 || ^3.0"，避免开放约束拖垮整个图 - 用
replace或conflict显式排除问题版本（例如"conflict": {"guzzlehttp/guzzle": "） - 升级关键中转包：如果
laravel/framework是瓶颈，先确认它是否支持你要的guzzle版本，再决定是否升 Laravel
最常被忽略的一点：菱形本身不可怕，可怕的是其中某条路径用了 dev-master 或 branch-alias 这类非稳定约束——它们会让 SAT 求解器失去版本锚点，大幅增加无解概率。
