composer 不按 require 顺序选版本，而是用 sat 求解器全局解析所有依赖约束（含 require、conflict、php 版本等）；改顺序无效，冲突由间接依赖引入，需用 composer why-not 或升级依赖解决。
Composer 里没有“版本覆盖”这回事——require 字段里谁写在前面、谁写在后面，对最终选哪个版本毫无影响。
为什么改 require 顺序完全没用
很多人以为把 "laravel/framework": "10.40.0" 放在 composer.json 的第一行，就能“压住”其他包带进来的 ^10.0。实际不是这样。Composer 不按书写顺序解析，而是把所有约束（包括间接依赖里的 require、conflict、PHP 版本限制）统一喂给 SAT 求解器，求一个全局满足的解。
常见错误现象：
- 执行
composer update报错Your requirements could not be resolved to an installable set of packages.，但你根本没在require里写冲突的包（比如symfony/polyfill-mbstring）——其实是某个你依赖的包（如guzzlehttp/guzzle）把它拉进来的，它的conflict规则参与了全局判断 - 手动把某个包从
require移到require-dev，结果composer install --no-dev还是失败——因为该包的约束可能已被其他生产依赖间接引入，地位完全平等
conflict 和 require 是同时生效的逻辑与关系
conflict 不是“装完再踢”，它和 require 一起构成 SAT 求解器的输入条件。例如：
"require": {
"monolog/monolog": "^2.0"
},
"conflict": {
"monolog/monolog": "
<p>这等价于要求：必须选 <code>monolog/monolog</code> 的一个版本，它既满足 <code>^2.0</code>（即 ≥2.0.0 且 ≥2.9.0。交集是 <code>2.9.0–2.99.99</code>，比如 <code>2.10.0</code> 可行，<code>2.8.0</code> 直接被排除。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill3855" title="Discussion Composer"><img
src="https://img.php.cn/upload/skill/000/000/081/178981577668913.jpg" alt="Discussion Composer" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill3855" title="Discussion Composer" class="overflowclass">Discussion Composer</a>
<p class="overflowclass">围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能：
- “write my discussion”
- “help me discuss my findings”
- “how do I compare to prior studies”
- “write the limitations par</p>
</div>
<a rel="nofollow" href="/xiazai/skill3855" title="Discussion Composer" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<p>关键点：</p>
- 没有“后写的覆盖先写的”，只有“所有约束必须同时为真”
-
conflict写得越细（比如"=3.0.0"），SAT 求解器要排除的变量越多，搜索空间越小，有时反而更容易找到解 - 误写
"monolog/monolog": "2.8.0"在conflict里，会直接让所有2.8.0版本不可选——哪怕它是唯一满足其他约束的版本
间接依赖的约束和你亲手写的 require 地位完全一样
你的项目 require 了 package-a:1.2，而 package-a 的 composer.json 里写了 "php": ">=8.2"，那么即使你本地 PHP 是 8.3，Composer 也会拒绝安装 package-a:1.2——因为这个 PHP 约束来自间接依赖，但它参与全局求解。
这意味着：
-
composer why-not php:8.3可能返回一堆你没见过的包名，它们都不是你直接 require 的，但它们的元数据（require、conflict）构成了当前无解的逻辑链 - 想绕过某个间接依赖的 PHP 限制？不能靠改自己项目的
require，得要么升级那个间接依赖（如果它有兼容 8.3 的新版），要么用--ignore-platform-reqs（仅调试，上线前必须删掉） -
composer show package-a查到的requires列表，就是它向全局求解器提交的硬性条件，和你写的没区别
真正容易被忽略的是：SAT 求解器对版本范围极其敏感。把 "some/package": "^3.0" 改成 "^3.1"，可能就砍掉了几十个旧版本变量，从而避开一条隐藏冲突路径——这不是“运气好”，是逻辑空间被精确收缩的结果。
