直接执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/即可生效，但必须同时满足三个硬性条件：带-g参数、键名为单数repo.packagist、第二参数composer为必填type值、URL须以https://开头且末尾带/；任一缺失均静默回退官方源，验证需输出完整JSON对象。
直接执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就能生效，但漏掉任意一个硬性条件——比如少斜杠、键名多写一个 s、漏掉中间的 composer 类型值——就会静默 fallback 到 https://packagist.org，你完全看不到报错，只觉得“还是慢”。
全局配置为什么总不生效？三个硬性条件缺一不可
Composer 2.x 不会提示错误，只会默默放弃你的配置。必须同时满足：
-
-g参数不能省：没它就只改当前目录的composer.json，换项目或新开终端就失效 - 键名必须是
repo.packagist（单数、全小写、不能是repos.packagist或packagist.org） - 第二参数必须是
composer——这是type值，不是可选注释，漏掉就等于没配 - URL 必须用
https://开头，且末尾带/：写成https://mirrors.aliyun.com/composer会拼出/composerpackages.json，返回 404
验证是否真生效？别信“命令没报错”
运行 composer config -g repo.packagist，输出必须是完整 JSON 对象：
{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}
如果返回空、null、报错 Key "repo.packagist" does not exist，或者仍显示 https://packagist.org，说明配置根本没写进去。Windows 用户改完需重启终端；Linux/macOS 若提示权限拒绝，先运行 chown -R $USER ~/.composer。
立即学习“PHP免费学习笔记（深入）”；
项目级配置比全局更可靠，尤其在 CI/CD 和团队协作中
宝塔后台用 www 用户跑命令，GitHub Actions 用 runner 用户，它们读不到你本地 root 或 $USER 的全局配置。进项目根目录后执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
这条命令会自动在 composer.json 的 repositories 字段里安全追加，前提是原 repositories 是对象（如 {}），不是数组（如 []）。如果报错，手动把 "repositories": [] 改成 "repositories": {} 再重试。切忌手写 "packagist.org": false，这会彻底关掉回退机制，镜像临时不同步时 composer install 直接失败。
换源后第一次 install 还卡住？删 vendor 和 composer.lock 再来
旧 composer.lock 记录的是官方源的包哈希和 dist URL，阿里云的路径映射不同，会导致校验失败或请求 404。不要跳过这步：
- 删掉项目下的
vendor/目录和composer.lock文件 - 运行
composer clear-cache - 再执行
composer install -vvv，看日志里请求的域名是不是mirrors.aliyun.com - 如果日志里仍有
packagist.org，说明项目级repositories字段覆盖了全局设置，或composer.json里有禁用语句
镜像只加速元数据拉取和包下载，不解决 composer update 卡在 Resolving dependencies 的问题——那得查 PHP 内存、Xdebug、config.platform.php 匹配度。
