必须同时满足三点：执行 composer config -g repo.packagist 输出含 "url": "https://mirrors.aliyun.com/composer/"；运行 composer clear-cache 清除旧元数据缓存；确认项目级 composer.json 未覆盖全局配置，否则镜像不生效。
不是网络差，是镜像根本没生效、缓存还在用 packagist.org 的旧元数据、并发下载压根没开——这三样不齐，换源等于白换。
怎么确认国内镜像源真的在用
很多人执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就以为搞定了，结果 composer install -vvv 日志里还是出现 https://packagist.org/packages.json。真正生效必须同时满足两点：
- 运行
composer config -g repo.packagist，输出里明确含"url": "https://mirrors.aliyun.com/composer/"（注意末尾斜杠不能少） - 执行
composer clear-cache，否则 Composer 会优先读本地缓存的海外索引，根本不发请求 - 项目级
composer.json里的repositories字段会覆盖全局配置；可用composer config --list和composer config --list --global对比确认实际生效的是哪个
parallel-downloads 设多少才真起作用
parallel-downloads 是 Composer 2.2+ 原生机制，只对 composer install 有效，composer update 仍需串行算依赖图。默认值是 3，基本等于没开。
- 推荐设为
10：composer config -g parallel-downloads 10 - 别盲目冲到 20：企业网络或低配 CI 容易触发
file_put_contents(): failed to open stream（临时文件竞争），降到 6–8 更稳 - 这个参数依赖镜像支持 HTTP/2 多路复用；阿里云、清华、腾讯镜像都支持，但私有源若不支持，设高了也白搭
- 运行
composer --version确认是 2.2+；若是 1.x，先composer self-update
为什么加了 --prefer-dist 还卡在 downloading
--prefer-dist 的作用是跳过 git clone，直接下 ZIP 包。但它有个硬前提：镜像必须已生效。国内镜像（如阿里云）几乎不缓存 source，只缓存 dist —— 镜像没切成功，--prefer-dist 就会 fallback 到慢速 source，甚至失败。
- 必须同步执行
composer clear-cache，否则缓存里还存着旧的 packages.json，Composer 会继续按旧地址拉校验信息 - 检查项目
composer.json是否含"prefer-source": true，它会覆盖全局--prefer-dist，必须手动删掉 - 某些包硬编码 GitHub URL（比如
"dist": {"url": "https://github.com/xxx/yyy/archive/"}），这类不会走镜像，会撞上 GitHub Rate Limit；报错含GithubRateLimitException就是它
CI 或部署时还能再砍掉哪些耗时环节
真正卡点往往不在下载本身，而在 autoload 生成、脚本执行和 lock 文件校验。开发阶段需要这些，但 CI 构建或生产部署时纯属冗余。
-
--no-autoloader：跳过生成vendor/autoload.php，后续用composer dump-autoload --optimize单独处理 -
--no-scripts：阻止执行post-install-cmd等钩子，避免意外触发前端构建、缓存清理等重型操作 -
--no-dev：非开发环境不装 dev-dependencies，省下大量包和校验时间 - 注意：
--no-autoloader和--no-scripts装出来的vendor不能直接跑 PHP，必须补一次composer dump-autoload --optimize
最容易被忽略的是：镜像 URL 拼错（比如少个 s 写成 repo.packagist）、用了已停更的源（如 packagist.phpcomposer.com 返回 404）、或者公司内网拦截了镜像域名却没测试连通性。验证永远比配置重要。
