Composer不用SAT求解器，而是自研回溯式依赖解析器，基于深度优先尝试与冲突驱动回退，将依赖规则映射为Package→[VersionConstraint]结构，通过Pool和RuleSet实现版本剪枝与择优选择，不生成CNF公式也不调用MiniSat/Z3等外部库。
Composer 不用 SAT 求解器，它用的是自研的回溯式依赖解析器。
Composer 的 resolver 根本不调用 MiniSat、Z3 或任何外部 SAT 库
所有声称“Composer 基于 SAT 求解器”的说法，都混淆了问题建模意图与实际实现。源码里找不到 MiniSat、Z3、sat-solver 等依赖，也没有 CNF 解析逻辑或 DPLL 步骤。核心求解类 BacktrackingSolver 位于 Composer\DependencyResolver 下，它的 tryToSolve() 方法是纯 PHP 实现的深度优先尝试 + 冲突驱动回退，不是调用外部求解器。
常见错误现象：
- 看到报错里有 “Resolving dependencies through SAT” 就以为真在跑 SAT —— 这只是日志字符串里的占位描述，2022 年后已逐步替换为更准确的 “Resolving dependencies”，但部分文档/旧日志仍残留该词
- 用
composer update -v看到 “Generating rules” 就推断正在构造 CNF —— 实际上RuleSet构建的是Package → [VersionConstraint]映射，不是布尔子句集合
conflict 和 require 在 resolver 中不是逻辑子句，而是剪枝条件
Composer 把每个包版本当作候选值，而非布尔变量。当遇到 "conflict": {"monolog/monolog": "3.0.0"}，resolver 不会生成 ¬monolog/monolog:3.0.0 子句，而是直接在 Pool::whatProvides() 阶段过滤掉该版本，跳过后续尝试。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
使用场景：
- 你写
"require": {"php": ">=8.2"}，resolver 不会把它转成“PHP≥8.2 必须为真”，而是每次选包前检查当前环境PHP_VERSION是否满足——这是运行时校验，不是逻辑蕴含 -
"replace": {"old/package": "*"}触发的是RuleSet::getRulesForPackage()的重定向查找，不是添加(¬old/package ∨ new/package)这类等价子句 - 同一包多个版本互斥，靠的是
Pool中的selectBestCandidate()单次择一机制，不是靠 CNF 的“至多一个为真”约束子句
为什么官方文档和社区长期误传“SAT 求解器”？
这个误解源于对“约束满足问题（CSP）”和“布尔可满足性问题（SAT）”的模糊混用。两者目标相似（找满足条件的解），但建模方式和求解路径完全不同：
- CSP（Composer 实际采用）：变量域是有限版本列表，约束是区间交集、排除列表、稳定性排序；求解靠启发式剪枝 + 回溯
- SAT：变量是无限布尔空间，约束必须转为合取范式（CNF），求解靠 unit propagation + conflict clause learning
性能影响明显：
- Composer 的回溯能在毫秒级解决中小项目依赖，因为剪枝极快（
Pool::whatProvides()是哈希查表） - 真用 SAT 建模 PHP 生态（数万个包、每个包数十个版本），CNF 公式规模会爆炸，内存常超 2GB，根本不可行
- Composer 报错信息如 “Conclusion: don’t install monolog/monolog 3.0.0” 来自回溯路径回溯，不是 SAT 的 unsat core 提取
真正容易被忽略的点是：resolver 的“确定性”来自 Pool 构建顺序和版本排序规则（stable → RC → beta → alpha → dev），而不是逻辑公式的语义唯一性。换一个私有仓库响应顺序，或者改一行 minimum-stability，就可能得到完全不同的解——这不是 SAT 求解器的特性，而是回溯式搜索对输入敏感的自然表现。
