Composer版本冲突本质是SAT求解器证明无解，即全局约束下不存在满足所有依赖的版本交集；报错“无解”是数学结论而非配置错误。
Composer 版本冲突不是配置写错了就能手动“覆盖”，而是 SAT 求解器在全局约束下找不到满足所有条件的版本组合——你看到的报错，是它明确告诉你：“这组要求，无解”。
为什么 composer update 突然报 conflict 而不是装上最新版
它根本没在“找最新”，而是在找唯一满足全部约束的版本交集。比如你写了 "monolog/monolog": "^2.0"，同时又通过某个间接依赖引入了 "conflict": {"monolog/monolog": ">=2.9.0"}，那最终可选范围就是 >=2.0.0 且 ；如果该包最新稳定版是 2.10.0，就真没得选。
- 别改 require 顺序——顺序不影响求解结果
- 用
composer why-not monolog/monolog:2.8.0查谁挡了路，比瞎猜快十倍 - 如果输出里出现
guzzlehttp/guzzle或symfony/polyfill-*这类你没直接 require 的包，说明是间接依赖带进来的约束在起作用 - 运行
composer show monolog/monolog看它当前实际安装的版本和 composer.json 中声明的约束是否一致，能快速排除 lock 文件被绕过的情况
私有包 + dev-main 导致的“伪冲突”
写 "my/private-package": "dev-main" 看似省事，实则把版本控制权交给了 Git 分支 HEAD。一旦 main 推了新 commit，composer update 就可能拉一个完全没测过的版本进来，而 lock 文件只记了 commit hash，下次 install 却因网络或缓存问题 fallback 到另一个 hash，直接触发兼容性断裂。
- 必须打语义化 tag：用
git tag v1.2.3 && git push origin v1.2.3（轻量 tag，非 annotated） - require 改成
"my/private-package": "^1.2"，再配composer config repositories.my-private vcs https://git.example.com/my/private-package - 真要临时用分支，至少锁 commit：
"my/private-package": "dev-main#abc1234"，否则 lock 文件形同虚设 - 别信 alias ——
dev-main只影响 autoload 和版本解析逻辑，不阻止 Composer 拉新 commit
composer.lock 被忽略时的典型表现
运行 composer install 却装出和团队不一致的依赖版本，八成是 composer.lock 没提交、被 .gitignore 错误过滤，或 CI 环境误用了 composer update。
-
git status看composer.lock是否在暂存区；CI 脚本里是否写了composer install --no-interaction（正确）而非composer update（危险） - CI 中禁用 lock 文件会导致每次构建拉取最新匹配版本，哪怕只是
monolog/monolog从 2.8.0 升到 2.8.1，也可能因日志格式微调引发告警误报 - 私有包若没打 Git tag，Composer 会 fallback 到这类分支别名，此时
composer.lock会记录具体 commit hash——删掉 lock 再 install，就可能切到另一个 commit - 当你把一个包从
require移到require-dev，它的子依赖不会自动从主依赖树中剔除——composer show看不到，但vendor/里还留着
PHP 平台约束怎么写才不翻车
写 "php": "^7.4 || ^8.0" 看似兼容，实则让 lock 文件失去意义：不同环境可能解出完全不同依赖树。Windows 和 Linux 下某些扩展（如 ext-sockets）默认状态也不同，本地能装，CI 上直接挂。
- 显式声明统一平台：
"config": {"platform": {"php": "8.1.0"}}，避免环境差异干扰求解 - 别用过于宽松的 PHP 约束，尤其在生产项目中；
^7.4允许升到 7.4.33，但^7.4 || ^8.0可能在不同机器上解出 7.x 或 8.x 两套依赖 - 已发布的包无法追溯修改 PHP 上限——v1.0.0 的
composer.json里写着"php": ">=7.0"，它就永远允许 PHP 8+；唯一干净做法是发 v1.0.1 并更新约束 - 手动改
composer.lock不行，它是快照，不是配置文件；改了等于废掉整个依赖一致性保障
最常被忽略的一点：当你发现某个包的 CHANGELOG 里 MINOR 版本频繁标 BREAKING，或者社区 issue 大量抱怨升级后崩溃，这时候 ^ 和 ~ 就只是心理安慰——直接写死 "vendor/pkg": "1.8.5"，并加注释说明原因，比赌作者守 SemVer 实在得多。
