composer换镜像源必须满足三个硬性条件：键名必须为repo.packagist（单数）、第二参数必须显式写composer（类型声明）、url须以https://开头且结尾带/，否则静默失效；验证需确认config输出为完整json且含正确镜像地址。
换镜像源不是“试试看”，而是必须做的第一步；但只换源不验证、不联动其他配置，90% 的场景下依然卡在 Resolving dependencies 或 Downloading 阶段。
为什么 composer config -g repo.packagist 总是不生效
这条命令不是“设个 URL”就行，它有三个硬性条件必须同时满足：
-
repo.packagist键名不能多写s（repos.packagist是 Composer 1.x 的旧写法，2.x+ 完全忽略，且不报错） - 第二参数必须显式写
composer，这是仓库类型声明，缺了就当没配 - URL 必须以
https://开头，且结尾带/（https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌ —— 少斜杠会导致路径拼接错误，返回 404）
验证是否真生效：运行 composer config -g repo.packagist，输出应为完整 JSON：{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}。如果为空、null 或仍是 packagist.org，说明根本没写进去。
宝塔、CI、systemd 里 composer install 还是慢
因为这些环境默认以非登录用户身份运行（如 www、runner、www-data），而 composer config -g 默认只写当前 shell 用户（比如 root）的配置。你在终端里跑得飞快，宝塔后台或 GitLab CI 却还在原地打转。
- 确认实际运行用户：宝塔里查 PHP 进程属主，CI 中看 runner 用户，systemd 查
User=配置项 - 用对应用户重配：
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI 脚本中别依赖全局配置，改用临时参数更可靠：
COMPOSER_MEMORY_LIMIT=-1 php -d xdebug.mode=off $(which composer) install --no-dev --prefer-dist --no-autoloader --no-scripts
项目级 repositories 覆盖全局配置的陷阱
执行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加 -g）会向 composer.json 的 repositories 数组追加一条 "packagist" 记录，不会清空已有私有 Git 源。但要注意：
- 如果项目
composer.json已手动定义了"repositories": []且里面没有"packagist"条目，该命令会补上 - 但如果已有
"packagist"条目（哪怕 URL 写错了），这条命令不会覆盖，只会静默失败 - 一旦
repositories数组存在，它就会完全屏蔽全局repo.packagist配置 —— 这是 Composer 的覆盖逻辑，不是 bug
排查方法：运行 composer config --list | grep repositories，看输出里是否含项目级定义；再用 -vvv 日志确认实际请求域名是不是镜像地址。
Resolving dependencies 卡住和镜像无关，但容易误判
这个阶段不走网络，纯本地 CPU 计算，镜像再快也救不了。常见真实原因包括：
- PHP 内存不足（
COMPOSER_MEMORY_LIMIT默认常为 128M），导致依赖图解析失败重试 —— 临时加COMPOSER_MEMORY_LIMIT=-1再试 - Xdebug 启用（
php -v可确认），会让解析慢 5–10 倍 —— 用php -d xdebug.mode=off $(which composer) install临时禁用 -
platform配置与实际 PHP 版本不匹配（如"php": "7.4"却在 PHP 8.2 上运行），触发降级查找逻辑 -
composer.lock残留已下线包的引用，导致回退搜索 —— 删掉vendor/和composer.lock，再用composer install --no-cache
真正影响镜像效果的，是后续的 Downloading 阶段；但很多人把卡在这里当成“镜像没起作用”，结果反复折腾配置，却漏掉了内存或 Xdebug 这类更关键的问题。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
