私有仓库没生效的根本原因是packagist.org默认隐式启用并兜底，必须在composer.json根级显式配置"packagist": false，否则私有仓库仅作补充；禁用后repositories数组才按从上到下顺序匹配。
私有仓库没生效，大概率是 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）的仓库胜出，后面的全忽略。这不是比对版本再选最优，而是「命中即停」。
所以，想让私有仓库优先，它就得放在数组最前面：
工作流任务拆解与模型编排技能。使用场景：(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 是开关前提——漏掉这一步，后面所有顺序调整都是白忙。
