直接换阿里云镜像源可解决90%部署卡顿问题，但需严格满足三要素：键名repo.packagist（单数）、type值为composer、url以/结尾；项目级配置比全局更可靠，且换源后必须clear-cache并重装依赖。
直接换阿里云镜像源，90% 的国内 PHP 项目部署卡顿问题当场消失。不是所有“配了镜像”的操作都有效——配置写错、缓存没清、路径拼接失败，都会导致 Composer 表面跑完命令，实际还在直连 packagist.org。
composer config -g repo.packagist 命令为什么总不生效
这条命令是全局镜像配置的核心，但极易因三个细节失效，且不报错、不提示，只静默失败：
-
repo.packagist键名不能多写一个s（repos.packagist是无效键，Composer 忽略） - 必须带
composer这个 type 值，漏掉就会 fallback 到默认源 - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，少斜杠会拼成https://mirrors.aliyun.com/composer/packages.json导致 404
验证是否真写进去了：composer config -g repo.packagist，输出应为完整 JSON 或至少是 URL 字符串；空、null、或仍显示 https://packagist.org，说明根本没生效。
项目级配置比全局更可靠，尤其在 CI/CD 和 Docker 中
全局配置依赖当前用户环境，在 GitHub Actions、GitLab CI、Docker 构建等场景下基本不可靠——容器里没有你的 ~/.config/composer/config.json，-g 就是白写。
正确做法是进项目根目录（含 composer.json），执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
该命令会自动向 composer.json 的 repositories 数组追加 packagist 条目，不破坏已有私有源，也不需要手动处理 JSON 格式。
注意：改完后必须删掉 vendor/ 和 composer.lock，再运行 composer install（不是 update），否则旧 lock 文件仍指向海外源的哈希值，会报 hash does not match。
换镜像后还卡在 Resolving dependencies？那不是镜像的问题
镜像只加速下载阶段（Downloading），不解决依赖解析卡顿。常见真实瓶颈有：
-
COMPOSER_MEMORY_LIMIT=-1临时提升内存限制，避免 PHP 内存不足中断解析 - 禁用 Xdebug：
php -d xdebug.mode=off $(which composer) install，启用时解析慢 5–10 倍 - 检查
composer.json中"platform"配置是否与实际 PHP 版本匹配，比如写"php": "7.4"却在 PHP 8.2 下运行，会触发大量降级查找 - 确认 DNS 解析正常，可临时加
--dns 223.5.5.5（阿里 DNS）绕过本地污染
验证是否真走镜像：加 -vvv 参数看日志，composer show topthink/think -vvv 2>&1 | grep "Downloading"，必须看到 mirrors.aliyun.com 才算真正生效。
Docker 构建中镜像配置容易被忽略的关键点
在 Dockerfile 里写 RUN composer config -g repo.packagist ... 几乎总是失败——多数官方 PHP 镜像（如 php:8.2-cli）压根没初始化 ~/.config/composer/ 目录，config -g 会静默跳过。
安全做法只有两种：
- 用项目级配置：
RUN composer config repo.packagist composer https://mirrors.aliyun.com/composer/（在WORKDIR下执行） - 或直接传参：
RUN composer install --repository=https://mirrors.aliyun.com/composer/
另外，务必在 composer install 前加 RUN composer clear-cache，否则构建缓存可能复用旧包元数据，掩盖镜像未生效的事实。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
