当前（2026年7月）真正稳定可用的 Composer 镜像只有三个：阿里云（https://mirrors.aliyun.com/composer/）、腾讯云（https://mirrors.cloud.tencent.com/composer/）、华为云（https://repo.huaweicloud.com/repository/php/）；HIT、清华、中科大等高校镜像的 /composer/ 路径均返回 404，服务未上线。
当前（2026年7月）真正稳定可用的 Composer 镜像只有三个
别再搜 HIT、清华、中科大镜像了——它们的 /composer/ 路径目前全部返回 404，不是你配置错，是服务根本没上线。实测能用且持续维护的只剩：
• https://mirrors.aliyun.com/composer/（阿里云，末尾必须带斜杠）
• https://mirrors.cloud.tencent.com/composer/（腾讯云，HTTPS 稳定，每 5 分钟同步）
• https://repo.huaweicloud.com/repository/php/（华为云，2026 年唯一官方背书地址，路径末尾不带斜杠但 composer config 会自动补全）
其他所谓“高校镜像”链接，基本是旧文档残留或指向已停服域名，直接跳过。
配错 repo.packagist 是静默失效的主因
90% 的“换源后还是慢”，根本不是镜像问题，而是命令写错了却无提示：
• 键名必须是 repo.packagist（单数，不是 repos.packagist 或 repositories）
• 中间那个 composer 是 type 值，不能省略、不能写成 composer.org 或留空
• URL 必须 HTTPS 开头，且 aliyun 和 tencent 地址末尾必须有斜杠，huaweicloud 地址末尾不加斜杠反而正确
验证是否生效，只看这一行输出：composer config -g repo.packagist，返回的必须是完整 JSON，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，否则就是没写进去。
全局配置在 CI/多用户环境下大概率不生效
你在本地终端跑通了 composer config -g，不代表 GitHub Actions、Docker 构建或宝塔面板里的 PHP 进程能读到它：
• CI 流水线通常以独立 runner 用户运行，~/.composer/config.json 不会被加载
• 宝塔默认用 www 用户执行 PHP，你用自己的账户配的全局配置无效
• 多人协作时，新人 clone 项目后行为不一致
更可靠的做法：进项目根目录，运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉 -g），它会自动写入 composer.json 的 repositories 字段；改完立刻删掉 vendor/ 和 composer.lock，再 composer install。
换源后卡在 “Resolving dependencies”？和镜像无关
镜像只加速元数据拉取和 ZIP 下载，不解决依赖解析慢的问题。如果 composer update 卡几十秒甚至几分钟在 Resolving dependencies 阶段，检查：
• composer.json 里 "php" 版本约束是否太宽，比如 "^7.4 || ^8.0 || ^8.1 || ^8.2"，会让 Composer 尝试所有组合
• 是否有大量未锁定的 dev- 分支依赖，例如 "monolog/monolog": "dev-main"，每次都要重新遍历整个分支历史
• 本地 ~/.composer/cache 是否损坏，可先运行 composer clear-cache
