阿里云镜像最常被推荐，因其同步延迟最低（约15分钟）、tls证书链稳定、南北用户延迟均低于60ms，且url容错性高、ssl错误概率最低，composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 是目前成功率最高的配置命令。
阿里云、腾讯云、清华源、安畅网络这四个镜像源当前真实可用且稳定，其余如 packagist.phpcomposer.com 已停服，HTTP 地址在 Composer 2.2+ 中默认被拒绝。
为什么阿里云镜像最常被推荐
它不是最快，但同步延迟最低（约15分钟），TLS证书链稳定，南北用户延迟均低于60ms，且 Composer 2.2+ 下极少静默 fallback。关键在于其 URL 格式容错性略高，对末尾斜杠缺失的拼接错误处理更友好（仍可能降级但不直接 404）。实测中遇到 SSL certificate problem 的概率最低。
-
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/是目前成功率最高的命令组合 - 教育网、企业内网 DNS 解析异常时，它比腾讯云更少出现
Connection refused - 不保留已下架包——这点和腾讯云一致，遇到
Package not found需先确认原包是否仍存在于packagist.org
清华源适合什么场景
高校及教育网用户首选，mirrors.tuna.tsinghua.edu.cn 背靠 CERNET，骨干网质量极佳，首字节延迟常低于20ms。但它的 provider 分片策略与阿里云略有不同：部分私有包或新发布包的索引更新会滞后1–2小时，尤其当包作者刚标记 abandoned 后，清华镜像可能仍返回旧 metadata。
- 适合 Laravel、Symfony 等主流框架项目，对
monolog、symfony/polyfill类高频更新包支持及时 - 不适合 CI/CD 中要求“秒级同步”的灰度发布流程
- 若项目含大量自定义 VCS 包（如
git@xxx），清华源不会代理这类请求，会直接回源，此时需额外配置repositories
腾讯云和安畅网络的差异化表现
腾讯云 CDN 覆盖广，华南地区下载速度峰值达9.2MB/s，但 provider 文件按月切分（如 provider-2026-08.json），若 Composer 请求了未同步的日期后缀，会降级重试，造成明显卡顿；安畅网络（php.cnpkg.org）则专注 Laravel 11 和 PHP 8.5 兼容包，入库速度最快，适合新项目快速启动，但镜像节点少，北方用户偶发 TLS 握手慢。
- 腾讯云 URL 必须严格以
/结尾，少斜杠会导致/composerpackages.json404，且不报错，只静默 fallback - 安畅网络不提供全量历史版本，
composer show vendor/package 1.2.3可能失败，仅保证最新稳定版可用 - 两者都不支持
path类型仓库，若项目用了"type": "path"，Composer 会绕过镜像直连本地路径，和镜像无关
换源后仍卡在 “Loading composer repositories” 怎么办
这不是镜像问题，是缓存没清干净。Composer 默认复用本地缓存的 packages.json 最多15分钟，哪怕镜像站已同步，你本地也不会重拉。更隐蔽的是，若之前配置失败过，缓存里可能还存着指向 packagist.org 的元数据，导致每次请求都先冲官方源撞一次墙。
- 必须执行
composer clear-cache，不能跳过 - 验证是否真走镜像：
composer install -vvv，看日志里Downloading行的域名是否为你配的镜像地址 - 如果
composer config -g repo.packagist输出为空、null或仍是https://packagist.org，说明配置根本没写进去，得重跑命令并检查权限（WSL/Docker 中~/.composer/可能不可写）
真正决定体验的，从来不是“哪个镜像最快”，而是你有没有踩中那几个静默失效的坑：键名拼错、漏掉 composer type、URL 少斜杠、缓存没清、项目级 repositories 字段存在却没显式声明 "packagist": false。
