深度解析Composer使用中的Repository优先级对包查找速度的影响-composer-PHP中文网

根本原因是composer按repositories数组从上到下线性查找，首个返回有效元数据的仓库即终止请求，不发起后续请求；必须将私有源置顶、显式添加{"packagist.org": false}于其后，并清理composer.lock与vendor才能生效。

深度解析composer使用中的repository优先级对包查找速度的影响

为什么改了`repositories`顺序却没加快包查找

根本原因不是“顺序没生效”，而是 Composer 在找到第一个能返回 200 OK + 有效 JSON 的仓库前，根本不会发后续请求——哪怕你把最快私有源放第一，只要前面某个镜像源（比如阿里云）返回了空 packages.json 或含同名占位包的元数据，Composer 就立刻停住，连你的源 URL 都不会碰。

常见卡点：

composer require myorg/utils 报错 Could not find package，但 curl -I https://my-company.example.com/packages.json 明明返回 200 —— 实际日志里压根没请求这个地址，因为前面的 https://mirrors.aliyun.com/composer/ 先返回了 {"packages":{}}
私有源用 Satis 构建，但没生成 provider-includes，导致 Composer 每次都拉全量 packages.json，体积大、解析慢，而你误以为是“顺序问题”
全局配置了阿里云镜像，但项目级 composer.json 里又写了 "https://packagist.org"，结果 Composer 优先走官方源（因未禁用），网络超时后才 fallback，全程不走镜像

`"packagist.org": false` 必须写对位置，否则所有优化归零

这个键值对不是开关，而是“终止符”：它告诉 Composer “别再隐式兜底了”，但它只在自己被遍历到时才起作用。如果写在私有源前面，Composer 查完私有源就直接跳到它、判定“无源可用”，报错退出；必须放在私有源之后、数组末尾。

正确结构示例：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

"repositories": [
  {
    "type": "composer",
    "url": "https://my-company.example.com"
  },
  {
    "packagist.org": false
  }
]

错误写法（全部无效）：

{"type": "composer", "url": "...", "packagist.org": false} —— 键嵌套在对象里，被忽略
"packagist": false 或 "packagist.com": false —— 键名拼错，不识别
写在 config 字段下，而非 repositories 数组里 —— 完全不参与仓库匹配

多个私有源共存时，顺序决定的是“谁先截胡”，不是“谁更快”

Composer 不会并发请求所有源，也不比对响应时间。它严格按 repositories 数组从上到下线性检查，第一个声明支持目标包的源胜出。所以：

把最稳定、元数据最全的私有源放最前 —— 它能覆盖最多包名，减少 fallback 次数
避免两个源都声明 "packages": {"myorg/utils": {...}} —— 第一个返回的版本被锁定，第二个源里更新的 v2.1.0 永远不会被看到
type: "vcs" 仓库（如 Git URL）不参与此流程，只在 composer require vendor/name 显式调用时触发，不能靠它提升通用包查找速度
用 composer show myorg/utils --all 看实际解析来源，确认是否命中预期源；加 -vvv 能看到完整请求链路，比如 Reading composer.json of myorg/utils (dev-main) 前面的 URL 才是真正在用的源

`composer.lock` 里存的是源哈希，换镜像不删锁文件就白配

Composer 安装时默认信任 composer.lock 记录的源地址和包哈希。如果你刚把 repositories 从阿里云切到公司内网源，但没删 vendor/ 和 composer.lock，Composer 仍会尝试从旧源下载——失败后才退化为重新解析，此时才真正走新配置，但已浪费大量时间。

实操建议：

切换镜像或私有源后，执行 rm -rf vendor/ composer.lock && composer install，强制重走完整流程
CI 环境中，在 composer install 前加 composer validate --strict，提前发现 lock 文件中源不可达的问题
团队协作时，composer.lock 必须提交 Git，但需确保其生成环境与部署环境仓库配置一致，否则本地快、线上慢

真实瓶颈往往不在“顺序”，而在元数据是否精准、是否禁用兜底、是否清理缓存。查不到包时，先看 -vvv 日志里到底请求了哪些 URL，而不是反复调整数组顺序。