Composer 依赖冲突报错本质是 SAT 求解器数学证明无解：将版本与约束转为布尔变量和逻辑子句，求是否存在满足所有规则的赋值；无解则明确报错，有解则输出 composer.lock 中的确定性可行解。
Composer 依赖冲突报错时，背后真正在“推理”的是 SAT 求解器
当你看到 Your requirements could not be resolved to an installable set of packages，这不是 Composer 在“随便试几个版本失败了”，而是它调用的 SAT 求解器已穷尽所有逻辑可能，并数学上证明无解。SAT（Boolean Satisfiability）本质是：给一堆“能/不能装某包某版本”的布尔变量，加上你写的 require、conflict、PHP 版本限制等规则，问“是否存在一组真假赋值，让所有规则同时为真？”——有，就给出方案；没有，就明确告诉你不可能。
-
monolog/monolog:2.0.0、monolog/monolog:2.1.1、symfony/console:6.4.3……每个都是独立布尔变量 -
"php": ">=8.1"→ 所有不满足 PHP 8.1+ 的包版本变量，直接被设为false -
"guzzlehttp/guzzle": "^7.0"和"laravel/framework": "^10.0"同时存在 → 若后者硬依赖guzzlehttp/guzzle:^8.0，两者约束交集为空，SAT 立即判定矛盾
这个过程不是靠“先装 A 再看 B 能不能装”的递归试探，所以不会卡在局部最优里反复绕弯。
为什么改个 ^2.0 就能让冲突消失？SAT 求解器对版本范围极其敏感
版本约束不是模糊匹配，而是被精确拆解成逻辑子句。例如：
-
^2.0→ 展开为monolog/monolog:2.0.0 ∨ 2.1.0 ∨ 2.9.9（但排除 3.0.0+） -
~2.5.0→ 只允许2.5.0 ∨ 2.5.1 ∨ … ∨ 2.5.99，连2.6.0都被排除
这意味着：哪怕只是把 "some/package": "^3.0" 改成 "^3.1"，就可能砍掉几十个旧版本变量，从而避开某个隐藏冲突路径。
- 如果两个包分别要求
foo/bar:^2.0和foo/bar:^2.5，它们有重叠（2.5–2.9），SAT 可选foo/bar:2.7.0 - 但如果一个是
^2.0，另一个是^3.0，交集为空 → 直接无解 -
!=2.3.0这类排除项，会显式生成“该变量必须为 false”的子句，影响传播效率
所以，看似微小的版本号调整，实则是大幅收缩 SAT 的搜索空间。
运行 composer update --dry-run -v 看到的“Resolving dependencies”阶段，就是 SAT 求解器在工作
这个阶段 Composer 并没下载任何包，而是在做三件事：
- 从 packagist.org 拉取所有相关包的
composer.json元数据（含每个版本的require/conflict） - 把全部信息编译成一个巨大的 CNF（合取范式）逻辑公式
- 启动求解器，用单元传播（unit propagation）、冲突分析（conflict-driven learning）等技术快速剪枝
Resolving dependencies through SAT solving... → Finding a satisfiable assignment for 12,487 variables and 43,102 clauses → Unit propagation fixed 892 variables → Conflict #17 at decision level 5: [laravel/framework:10.0.0, guzzlehttp/guzzle:7.0.0] → Learning clause: (¬laravel/framework:10.0.0 ∨ ¬guzzlehttp/guzzle:7.0.0)
这些日志不是 debug 信息，是求解器真实的推理痕迹。它一旦学到 (¬A ∨ ¬B) 这条新子句，后续就永远不会再同时尝试 A 和 B —— 这正是它比纯回溯快得多的关键。
composer.lock 不是日志，而是 SAT 求解器输出的“已验证可行解”
composer.lock 文件里记录的不是“上次装了什么”，而是“经 SAT 求解器验证过的、满足全部约束的一组变量赋值”。下次 composer install 完全跳过求解，直接复用这个答案。
- 手动修改
composer.lock中某个包的version字段 → 相当于强行替换一个已被数学验证的解，很可能导致composer install失败或运行时报错 - 删除
composer.lock后只跑composer install→ Composer 会报错，因为没锁文件就无法跳过求解，而 install 默认不触发解析（需 update） -
composer update --lock是安全的，它只更新 lock 文件中的哈希与源地址，不改动版本选择
真正容易被忽略的是：SAT 求解的结果具有确定性，但它的输入（元数据缓存、仓库响应顺序、PHP 平台约束）稍有变化，就可能导致不同机器上得到不同解——所以 lock 文件不可替代。
