Composer的仓库机制包含canonical源（如Packagist.org）和镜像仓库（如阿里云镜像），前者是官方权威源，后者用于加速访问；配置镜像时可通过设置fallback实现失败回退，适用于网络受限或需确保依赖安全可信的场景。
当你在使用 Composer 安装 PHP 包时，可能会注意到某些包来自不同的源。这背后其实涉及 Composer 的仓库机制，尤其是“canonical”仓库和镜像仓库之间的区别。理解它们有助于你更清楚依赖的来源、加载顺序以及网络优化策略。
什么是 "canonical" 仓库？
Canonical（官方源）指的是包原始、权威的存储位置。对于大多数开源 PHP 包来说，这个位置通常是 Packagist.org。它是 Composer 默认启用的中央仓库，所有公开的 Composer 包都会在这里注册。
当一个库作者发布新版本时，他们向 Packagist 提交信息，其他用户通过 Composer 安装该包时，默认就会从这里获取元数据（如版本号、依赖关系等）和下载链接。
关键点：
- 只有一个 canonical 源，通常是 Packagist。
- 它保存了最完整的包信息和最新状态。
- Composer 在没有配置自定义仓库时，自动使用它。
镜像仓库的作用是什么？
镜像仓库是 canonical 仓库的副本，通常由第三方或组织维护，目的是提升访问速度或绕过网络限制。例如，在中国，由于网络原因直接访问 packagist.org 较慢，开发者常使用 阿里云、Laravel China 或 Huawei Cloud 的镜像。
镜像定期同步 canonical 源的数据，提供相同的包列表和版本，但托管在地理位置更近或更快的服务器上。
你可以通过以下命令设置全局镜像：
这样 Composer 就会优先从镜像拉取数据，而不是原始源。
仓库优先级与回退机制如何工作？
Composer 并不会同时查询多个仓库来“比较”哪个更快。它的行为基于配置顺序和类型：
- 如果你配置了一个镜像，并将其设为
composer类型（即代理模式），Composer 只会请求这个镜像，不再访问 canonical 源。 - 如果镜像不可达或返回 404，Composer 不会自动回退到原始源，除非你显式配置了 fallback 行为。
- 如果你想让 Composer 在镜像失败后尝试主站，可以添加如下配置：
注意：第二个仓库名称不能重复，因此用 packagist-fallback 区分。Composer 会按配置顺序尝试，直到找到所需资源。
不过要注意，有些镜像本身已经做了反向代理，即使你配置了 fallback，可能也感知不到失败，因为镜像服务端已处理了转发。
总结：何时关心 canonical 和镜像的区别？
大多数情况下，你只需知道镜像是为了加速下载。但在以下场景中，理解差异很重要：
- 你发现某个新发布的版本在本地无法安装 —— 可能是镜像未及时同步。
- 你需要确保依赖来自可信源（比如审计安全）—— 应确认是否仍连接的是官方 canonical 源。
- 企业内网搭建私有镜像时，需要设计合理的同步与降级策略。
基本上就这些。Composer 的仓库机制看似简单，但在复杂网络环境下，合理配置能显著提升开发效率和稳定性。
