切换镜像后 Composer 仍连 GitHub 是因镜像仅加速元数据（packages.json）查询，不接管 dist 包下载；composer.lock 中的 dist.url 仍为原始地址，需执行 composer update --lock 或删除 lock 文件重建才能生效。
切换镜像后 Composer 还去连 GitHub，不是配置没生效，而是你混淆了「元数据源」和「代码下载源」——镜像只管 packages.json 查询，不管 source.url 下载。
镜像只加速元数据，不接管 dist 包下载
Composer 的依赖解析分两步：先查包列表（metadata），再拉 ZIP 或克隆代码（dist/source）。国内镜像（如阿里云、清华源）只代理前者，后者仍按 composer.lock 里记录的原始地址走。比如锁文件中某包的 dist.url 是 https://api.github.com/.../zipball/xxx，哪怕你切了镜像，Composer 依然会直连 GitHub 下载这个 ZIP。
- 执行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/只影响第一步 - 检查
composer.lock文件，搜索"dist": {.*?"url"，能看到大量github.com或api.github.com地址 - 这类 URL 不会被镜像重写，除非你强制刷新 lock 文件
必须刷新 composer.lock 才能让新镜像真正生效
composer.lock 锁定的是具体版本 + 完整下载路径，它不会自动感知镜像变更。旧 lock 文件里的 dist URL 还是 packagist.org 时代的原始地址，所以 install 时照旧连 GitHub。
GitHub Actions Runtime Regression Audit
下载
对比基线与当前 GitHub Actions 运行导出，在 CI 成本和交付周期激增前及时发现工作流或作业运行时性能退化。
- 运行
composer update --lock：仅更新 lock 文件中的 URL，不改依赖版本，最快最安全 - 或删掉
composer.lock和vendor/，再跑composer install：彻底重建，适合调试 - 别跳过
--lock参数——省略它等于白切镜像
GitHub 克隆卡住？那是 Git 协议问题，跟镜像无关
如果卡在 Cloning into 'xxx'，说明 Composer 正调用 git clone 拉源码，而 Git 默认可能用 git:// 或 ssh:// 协议，这两者在国内基本不可用。
- 执行
composer config --global github-protocols https，强制把所有 GitHub 地址转成https://github.com/xxx/yyy.git - 同时配好 Git 的 HTTPS 代理：
git config --global https.proxy http://127.0.0.1:7890 - 验证是否生效：
composer show vendor/package | grep source，输出应为https://开头
最容易被忽略的一点：composer.lock 里存的不只是版本号，还有每个包的完整下载地址。切镜像不删 lock，就像换了快递公司却还用旧运单——地址没更新，货照样发错地方。
