项目级配置比全局更可靠,因交付环境(如Docker、GitHub Actions)中composer config -g常因用户权限、目录未初始化或优先级被覆盖而失效;应改composer.json的repositories数组,首项禁用packagist.org,次项配镜像源,并删vendor与lock后重装。
直接改项目级 composer.json 的 repositories 字段,比全局配置更可靠——尤其在交付、CI 或多用户环境里,composer config -g 很可能压根不生效。
composer config -g 在交付时大概率失效交付环境(如宝塔、Docker、GitHub Actions)里真正执行 composer install 的用户,往往不是你本地的 root 或当前登录用户。比如:
www 用户运行,读的是 /home/www/.composer/config.json,不是你的 /root/.composer/config.json
php:8.2-cli)压根没初始化 ~/.composer 目录,composer config -g 会静默失败php-actions/composer 动作默认忽略全局配置,只认项目根目录下的 composer.json
更麻烦的是:拼错键名(比如写成 repos.packagist)、漏掉 -g、URL 少斜杠,命令都不报错,但查 composer config -g repo.packagist 输出为空——你根本不知道配错了。
composer.json 里怎么安全加镜像源进项目根目录,执行这条命令即可(不加 -g):
立即学习“PHP免费学习笔记(深入)”;
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
它会自动往 composer.json 的 repositories 字段里追加条目,不破坏原有结构。但要注意:
"repositories": {}(空对象),这条命令会覆盖整个字段;想保留私有源,得手动编辑成数组格式"repositories": [](空数组),命令会报错,需先改成 "repositories": [ ] 再重试{"type":"packagist", "url":"https://packagist.org"} 作为 fallback,否则新包未同步时直接失败vendor/ 和 composer.lock,再跑 composer install——旧 lock 文件里的 dist URL 可能还指向 packagist.org
在 GitHub Actions 或 GitLab CI 里,别用 composer config -g,而是显式作用于当前项目:
composer config --no-interaction --working-dir=. repositories.packagist composer https://mirrors.aliyun.com/composer/ && composer install
这条命令的关键点:
--no-interaction 防止交互式提示中断流水线--working-dir=. 确保配置只写进当前项目,不依赖用户主目录&& 连写,避免中间步骤失败后残留错误配置vendor/ 和 composer.lock,绝对不要缓存 ~/.composer/——不同项目的镜像配置会互相干扰别信“好像快了”,也别只看 composer diagnose——它只校验语法,不反映真实请求路径。真正有效的验证只有:
composer update -vvv,盯住日志里每一条 Downloading 行,域名必须是 mirrors.aliyun.com 或对应镜像域名packagist.org 或 github.com,说明 composer.lock 里硬编码了原始地址,必须删 lock 文件重装curl -o /dev/null -s -w "%{time_total}n" https://mirrors.aliyun.com/composer/packages.json 对比各镜像响应时间,腾讯云镜像在腾讯云 CVM 上实测首包延迟低 30–50ms交付前最容易被忽略的一点:镜像只加速下载,不解决依赖解析卡顿。如果 Resolving dependencies 阶段慢,要检查 PHP 内存限制、Xdebug 是否启用、platform 配置是否与实际 PHP 版本匹配——这些和镜像无关,但常被误认为“镜像没起作用”。