Composer怎么设置仓库优先级？精细化管理依赖源-composer-PHP中文网

私有仓库没生效的根本原因是packagist.org默认隐式启用并兜底，必须在composer.json根级显式配置"packagist": false，否则私有仓库仅作补充；禁用后repositories数组才按从上到下顺序匹配。

composer怎么设置仓库优先级？精细化管理依赖源

私有仓库没生效，大概率是 packagist.org 还开着

Composer 默认会隐式启用 packagist.org，且把它当作兜底源——哪怕你把私有仓库写在 repositories 数组最前面，它也**永远排在最后被查**。结果就是：你的私有包 mycorp/utils 一 require，Composer 先去 packagist.org 找，404 了才轮到你配的私有源；但更糟的是，如果 packagist.org 上恰好有同名包（哪怕只是个空壳），它就直接返回元数据，后续仓库全被跳过。

必须显式禁用默认源："packagist": false 要放在 composer.json 的顶层（不是 repositories 里），且不能写成 {"packagist": false} 放在数组中间——那会被当成一个无效仓库项，还可能报错。

"packagist": false 必须是根级字段，和 repositories、require 并列
禁用后，所有包都得靠你手动声明的仓库提供，repositories 数组顺序才真正起作用
别用 composer config -g repos.packagist false，这是全局操作，会破坏其他项目

repositories 数组顺序决定“谁先说话”

禁用 packagist.org 后，Composer 严格按 repositories 数组**从上到下**扫描：第一个能返回目标包元数据（非 404）的仓库胜出，后面的全忽略。这不是比对版本再选最优，而是「命中即停」。

所以，想让私有仓库优先，它就得放在数组最前面：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

{
  "repositories": [
    { "type": "composer", "url": "https://repo.mycorp.com" },
    { "type": "composer", "url": "https://mirrors.aliyun.com/composer/" },
    { "type": "composer", "url": "https://packagist.org" }
  ],
  "packagist": false
}

私有源放第一：确保 mycorp/* 类包第一时间被它响应
镜像源放第二：覆盖大部分公开包，比官方快、稳
官方源放第三：仅作最终 fallback，防镜像临时不可用
千万别同时写 https://packagist.org 和镜像地址——Composer 会优先连原站，断网就失败，镜像根本不会触发

vcs 类型仓库不参与全局匹配，只对显式 require 生效

如果你用 "type": "vcs" 配了个 Git 地址，比如 "url": "https://gitlab.mycorp.com/mycorp/utils"，它**不会出现在 packages.json 的全局索引里**。Composer 不会拿它去匹配所有 require 中的包名，只会在你明确运行 composer require mycorp/utils 时，单独拉这个仓库的 composer.json 来解析版本。

适合临时 fork、单点 patch，不适合做企业级私有源统一管理
无法覆盖 laravel/framework 这类基础包——除非你在 require 里写死 "laravel/framework": "dev-my-fork as 10.48.0"
要让它“参与竞争”，得换成 "type": "composer"，并确保其 packages.json 明确列出了该包名（"providers" 字段）
返回 403 或 500 时，Composer 默认静默跳过，不会报错，容易误判为“配置生效”

验证优先级是否真生效，别光看配置

光检查 composer.json 顺序没用。真正要看的是 Composer 实际请求了哪个源。最可靠的方式是加详细日志：

运行 composer update -vvv mycorp/utils，观察输出中是否有类似这样的行：

Reading composer.json of https://repo.mycorp.com/packages.json
Found package "mycorp/utils" in version "2.3.1"

如果日志里压根没出现你的私有源 URL，说明它根本没被查询——大概率是 "packagist": false 没生效，或 URL 拼错/HTTP 404
如果看到 Skipping package "mycorp/utils" (not provided) 出现在私有源之后，说明它的 packages.json 没声明这个包
composer show mycorp/utils 只显示已安装包的来源，不反映解析过程，不能用来验证优先级

复杂点在于：不同 type 的仓库（composer / vcs / package）匹配逻辑完全不同，而 "packagist": false 是开关前提——漏掉这一步，后面所有顺序调整都是白忙。