composer仓库顺序仅对“命中的包”生效，即从上到下扫描首个提供目标包完整元数据的仓库即停止；必须禁用packagist.org并确保私有源packages.json明确声明该包。
Composer仓库顺序就是优先级，但只对“命中的包”生效
Composer的repositories数组顺序决定查找优先级——从上到下扫描，第一个能提供目标包完整元数据（即包含该vendor/package且有可用版本）的仓库，就会被采用，后续仓库彻底跳过。这不是“试错重试”，而是“命中即停”。
常见错误现象：composer update laravel/framework 仍从 packagist.org 下载，明明你加了私有 fork 源；原因往往是没禁用默认源，或 fork 源的 packages.json 里根本没声明这个包。
- 必须在
repositories顶部加{"packagist.org": false}，否则官方源永远兜底，你的私有源再靠前也白搭 - 私有 Composer 源（type: "composer"）必须已生成并公开
packages.json，且其中providers明确列出了你要覆盖的包名（如"laravel/framework"） - VCS 类型（type: "vcs"）仓库不参与全局元数据合并，只在运行时按需克隆——它只对
require中显式指定的包生效，且不触发“fallback”逻辑
怎么验证哪个仓库真正在起作用？
光看 composer.json 里的顺序没用，得看 Composer 实际行为。最直接的方式是加详细日志跑一次更新。
使用 composer update -vvv vendor/package，你会看到类似这样的输出：
Reading composer.json of packagist.org (https://repo.packagist.org/packages.json) Skipping package "laravel/framework" (not provided) Reading composer.json of https://repo.dev/forked-laravel/packages.json Found package "laravel/framework" in version "10.48.12"
这说明它先查了 packagist.org，跳过了；再查你配的第一个私有源，命中了——顺序和内容都对上了。
-
composer show vendor/package会显示当前安装版本的来源 URL，但注意：它只反映已安装状态，不反映解析过程 - 如果
-vvv日志里压根没出现你配的私有源 URL，说明它连元数据都没去拉——大概率是packagist.org还开着，或者源地址拼错了、HTTP 404 了 - 私有源返回 403 或 500 时，Composer 默认静默跳过，不会报错，只会继续往下找——容易误以为“配置生效了”，其实只是被绕过去了
多个私有源之间怎么避免互相干扰？
同名包出现在多个私有源里，是典型的“不可控冲突点”。Composer 不做版本比对，只取第一个匹配项；而这个“第一个”，取决于你写的顺序，也取决于缓存、网络响应时间甚至 DNS 解析结果。
比如两个源都提供 acme/log v2.1.0，但代码不同，你永远无法保证 CI 流水线每次构建都从同一个源拉——除非你彻底隔离。
- 强制命名空间前缀：公司级包统一用
company/acme-log，部门级用team/utils，临时 fork 用dev/laravel-framework，从源头消灭同名可能 - 用
replace或provide在composer.json中显式声明替代关系，例如："replace": {"laravel/framework": "self.version"}，让 Composer 知道“我这个包就是它的替代品”，而非依赖仓库顺序去抢 - 开发环境用
composer config repositories.xxx动态增删，上线前务必--unset所有临时源，防止配置残留污染生产构建
命令行配置 vs 写死在 composer.json，选哪个？
用 composer config repositories.foo composer https://xxx 看似方便，但它写进的是全局 ~/.composer/config.json，影响所有项目。CI/CD 中尤其危险——一个项目的私有源配置，可能让另一个项目意外拉错包。
真正可控的做法，是把所有仓库声明收束到项目级 composer.json 的 repositories 数组里，并通过 Git 分支或环境变量（配合脚本注入）来切换不同环境的源列表。
- CI 脚本中可执行：
sed -i 's|https://dev.repo|https://prod.repo|g' composer.json，再composer update——比全局 config 更透明、更可追溯 - 若必须用命令行动态配置，请限定 scope：
composer config --local repositories.foo ...，确保只写入当前项目目录下的composer.json - Composer 7+ 默认禁用插件，若私有源依赖自定义插件（如认证钩子），还需在
composer.json中显式配置allow-plugins白名单，否则仓库请求直接失败
