composer config -g repo.packagist 失败主因是 php disable_functions 拦截 proc_open/putenv，需检查 php.ini、重启服务、验证函数可用性，并确保命令格式完全正确（键名 repo.packagist、type 小写 composer、url 以 https:// 开头且结尾带 /）。
composer config -g repo.packagist 命令为什么总失败
不是镜像地址失效，而是 PHP 环境拦住了 Composer 启动所需的底层函数。常见报错包括 proc_open(): fork failed、putenv() has been disabled，甚至直接 command not found（其实是 PHP CLI 模块没加载成功）。关键检查点有三个：
-
php.ini中的disable_functions列表里不能出现proc_open和putenv—— 多一个空格也会导致失效 - 改完
php.ini后必须重启 PHP-FPM（或 Apache/Nginx）；CLI 模式下也要重开终端或执行hash -r清命令缓存 - 验证是否真通：运行
php -r "echo proc_open('echo 1', [], $p) ? 'ok' : 'fail';"，输出ok才算过关
配置命令必须写对这三处，缺一不可
这条命令：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 看似简单，但错一个字符就静默失效——不会报错，但请求照旧发往 packagist.org。
-
repo.packagist是固定键名，写成repos.packagist或repository.packagist都不生效 -
composer是 type 字段值（小写），不是命令名，漏掉它，Composer 就当没这回事 - URL 必须以
https://开头，且末尾带/，比如https://mirrors.aliyun.com/composer/✅，而https://mirrors.aliyun.com/composer❌（部分 Composer 7.x 版本会 404）
项目里有 repositories 字段，全局镜像还管用吗
不管用。Composer 的仓库优先级是：项目级 composer.json > 用户级 ~/.composer/config.json > 官方默认源。只要项目根目录的 composer.json 里定义了 repositories 数组，哪怕只写了 {"packagist.org": false}，全局配置就会被完全忽略。
- 想临时绕过项目配置验证镜像是否可用？加
--repository-url参数：composer update --repository-url=https://mirrors.aliyun.com/composer/ -
composer create-project不支持-r参数，CI 脚本中若要用镜像，必须先config -g再执行，不能靠临时参数 - 某些 IDE（如 PHPStorm）会缓存 Composer 配置，改完全局设置后需重启 IDE 才能识别
怎么确认镜像真的在用，而不是“看起来生效”
别只信 composer config -g repo.packagist 的输出，它只显示你设了什么，不显示是否被覆盖或是否生效。最可靠的验证方式是看真实 HTTP 请求。
- 运行
composer clear-cache && composer require monolog/monolog -vvv 2>&1 | grep "GET\|Downloading"，观察 URL 是否含mirrors.aliyun.com - 或者更轻量：
composer show -v | head -n 5，日志里第一行出现的Downloading https://...地址才是真实请求源 - 如果看到
packagist.org或repo.packagist.org，说明没生效；如果看到phpcomposer.com或laravel-china.org，说明用了过期地址，大概率卡住或 500
真正容易被忽略的是：镜像只改下载路径，不解决 PHP 扩展缺失、SSL 证书异常、DNS 污染或中间代理劫持的问题。如果配完还是慢或报错，先查 composer diagnose 输出里的 Repo packagist.org is default 这类提示，再往下排查网络层。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
