命令必须严格为composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，错一个字符（如多s、少/、漏composer、缺-g）即静默失效；验证需composer config -g repo.packagist输出完整JSON且含阿里云URL，并用composer install -vvv | grep mirrors\.aliyun确认日志调用镜像。
直接用这条命令就能生效，但必须一字不差：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
为什么这条命令总“看起来成功”却没效果
它不报错，也不提示失败，只要错一个字符就静默回退到 packagist.org。常见失效点：
-
repo.packagist写成repos.packagist（多一个 s）或packagist.org—— 键名必须是单数、小写、严格匹配 - 漏掉中间的
composer—— 这是type值，不是注释，不是可选参数 - URL 少了末尾
/，比如写成https://mirrors.aliyun.com/composer—— 会导致请求路径变成/composerpackages.json，404 - 没加
-g—— 不加就只改当前目录下的composer.json，换项目或新开终端就失效
验证是否真生效，别信“执行完就 OK”
运行：composer config -g repo.packagist
输出必须是完整 JSON 对象，例如：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
如果返回空、null、Key "repo.packagist" does not exist，或者只有一行 URL 字符串（尤其是还显示 packagist.org），说明根本没写进去。
再补一刀验证：跑一次 composer install -vvv 2>&1 | grep -i 'mirrors.aliyun'，日志里得出现镜像域名；如果还看到 packagist.org/packages.json，就是还在直连官方源。
项目级配置比全局更可靠，尤其在 CI/CD 和团队协作中
全局配置写在 ~/.composer/config.json，但宝塔用 www 用户、GitHub Actions 用 runner 用户、Docker 容器常以非登录用户运行——它们压根读不到你配的那条。
进项目根目录（确保有 composer.json），执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意去掉 -g）
这条命令会自动向 composer.json 的 repositories 字段安全追加 "packagist" 条目，不会覆盖已有私有源。但要注意：
- 如果
repositories原来是数组[]，命令会失败；需先手动改成对象{}再重试 - 改完必须删掉
vendor/和composer.lock，再跑composer install --no-cache—— 否则旧 lock 文件仍指向官方源，哈希校验必报错 - 别手动硬编码
"repositories": [{"type":"composer","url":"..."}]，这会让 Composer 把镜像当成普通补充源，而不是主源替代
最易被忽略的一点：换源后卡在 Resolving dependencies，和镜像完全无关。那是依赖解析阶段，镜像只加速下载环节（Downloading、Fetching package）。这时候该收紧 PHP 版本约束、清理 require-dev、或检查是否用了已废弃的 fxp/composer-asset-plugin。
