composer依赖解析无全局优先级，依赖约束叠加、仓库顺序和稳定性过滤三重机制协同；repositories顺序决定查找路径，但packagist.org隐式排在最后，私有包应使用"type":"package"显式声明并避免覆盖公共包。

Composer 的依赖解析没有“全局优先级”概念，它靠的是约束叠加 + 仓库顺序 + 稳定性过滤三重机制共同作用——任何单一维度的调整都可能被其他维度覆盖或抵消。

repositories 数组顺序决定包来源，但不是“越靠前越优先”

很多人误以为把私有仓库写在 repositories 数组开头就能“优先进入解析”，实际行为是：Composer 按数组顺序从上到下查找，第一个返回匹配元数据的仓库即被采用，后续仓库完全不查。这看似是“靠前优先”，但关键陷阱在于：packagist.org 是隐式存在的，且默认排在所有显式仓库之后。

常见错误配置：

• 把私有仓库放在数组末尾，又没显式声明 {"packagist.org": false} → Composer 先查 packagist.org，同名包直接命中，私有仓库根本没机会生效
• 用 "type": "composer" 指向私有仓库 URL，却未限制只提供特定包 → 它会响应所有包查询，导致意外覆盖公共包（比如把 monolog/monolog 的旧版私有 fork 当作唯一候选）
• 多个 vcs 类型仓库并存，但没做 name 去重校验 → 若两个仓库都声明了 myorg/utils，只有第一个被扫描到的版本进入求解器，第二个被静默丢弃

正确做法是：私有包必须用 "type": "package" 显式声明，只包含你真正要 override 的 name、version 和 dist 地址；其余包交由 packagist.org（或代理镜像）兜底，并显式保留 {"packagist.org": true} 在数组末尾。

require 与 conflict 不是“谁写在前面谁赢”，而是逻辑合取

require 和 conflict 字段在 SAT 求解阶段被统一转译为布尔逻辑子句，不存在语法位置优先级。比如：

"require": {
    "symfony/console": "^6.0",
    "php": ">=8.1"
},
"conflict": {
    "php": "
<p>这两条约束会被合并为同一组 CNF 表达式，求解器只关心是否存在满足全部条件的版本组合。如果 <code>symfony/console ^6.0</code> 的某个版本要求 <code>php: >=8.0</code>，而你的 <code>conflict</code> 又排除了 <code>，那这个版本就因违反 <code>php</code> 约束被剔除——不是 <code>conflict</code> 覆盖了 <code>require</code>，而是二者共同否决了该选项。</code></p><div class="aritcle_card flexRow artxards">
											<div class="artcardd flexRow">
												<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill2443" title="First Principles Decomposer"><img
														src="https://img.php.cn/upload/skill/000/000/081/178909565751910.jpg" alt="First Principles Decomposer" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
												<div class="aritcle_card_info flexColumn">
													<a rel="nofollow" href="/xiazai/skill2443" title="First Principles Decomposer" class="overflowclass">First Principles Decomposer</a>
													<p class="overflowclass">把任何问题拆解为根本真理，再从原子层面重建解决方案。</p>
												</div>
												<a rel="nofollow" href="/xiazai/skill2443" title="First Principles Decomposer" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
												</a>
											</div>
										</div>
<p>容易踩的坑：</p>

• 在 require-dev 中引入和 require 冲突的包（如 "monolog/monolog": "^1.0"），composer update 仍会报错——因为求解器看到的是整个依赖图，dev 包参与求解
• 用 replace 替换包时未同步加 conflict → 可能导致旧包残留，引发类加载冲突

minimum-stability 和 prefer-stable 是稳定性闸门，不是排序权重

minimum-stability 是硬性过滤器，按 dev 严格分级。设为 <code>"beta" 就意味着所有 alpha 和 dev 版本直接从候选池清除，哪怕它们是唯一满足 require 约束的版本。

prefer-stable 不改变过滤规则，只在多个满足 minimum-stability 的版本中倾向选择更稳定的那个。例如：

• "minimum-stability": "beta" + "prefer-stable": true → 在 2.10.0-beta1 和 2.10.0-rc1 都可用时，选 rc1；但若只有 2.10.0-beta1 和 2.9.0（stable），则仍可选 2.9.0
• "minimum-stability": "stable" → 所有 RC 版本被过滤，哪怕它已通过全部测试、只差打 tag

临时安装不稳定版本必须用 @dev 后缀（如 composer require myorg/utils:dev-main@dev），否则会被 minimum-stability 拦截。

composer.lock 是解析结果快照，不是配置源

composer.lock 文件记录的是上一次成功求解出的精确版本组合，它本身不参与新一次的依赖解析决策。但它的存在会影响行为：

• 执行 composer install 时，Composer 直接读取 lock 文件安装，跳过求解过程 —— 此时 repositories 顺序、minimum-stability 等配置仅用于校验锁文件合法性，不触发重新计算
• 执行 composer update 或修改 composer.json 后再 install，才会重新运行 SAT 求解器，此时所有配置项才真正生效
• 若 lock 文件里记录了来自私有仓库的包，但当前 repositories 数组已移除该源 → install 会失败，报错 Could not find package xxx at version yyy，因为无法验证 dist URL

最易被忽略的一点：当你切换团队成员、CI 环境或更换私有仓库地址时，composer.lock 里的源信息不会自动更新，必须 composer update --lock 强制重写锁文件，否则旧源失效会导致部署中断。