全局配置命令composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/必须严格满足三要素：键名repo.packagist（非repos）、composer为必填type值、url须https且末尾带斜杠，缺一即静默失效；验证需运行composer config -g repo.packagist输出完整json。
全局配置一条命令就能生效，但90%的人配不成功——不是网络问题，是命令写错了三个关键点。
composer config -g repo.packagist 命令必须带齐三要素
这条命令静默失败的概率极高，漏掉任意一个都不会报错，但镜像完全不生效：
-
-g不能省：缺了就只改当前项目composer.json，换目录或新开终端就失效 -
repo.packagist是唯一合法键名（注意是repo单数，不是repos；也不能写成packagist.org） -
composer是type值，不是可选参数——省略后 Composer 2.0+ 会 fallback 到官方源 -
https://mirrors.aliyun.com/composer/必须用 HTTPS，且末尾斜杠/不能少（少斜杠会拼出/composerpackages.json导致 404）
正确写法：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
验证是否真正生效，别信“执行完就完了”
运行 composer config -g repo.packagist，输出必须是完整 JSON 对象：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
如果返回空、null、报错，或者只显示 https://packagist.org，说明没写对。常见原因包括：
- 手动编辑过
~/.composer/config.json，JSON 格式错误（比如多逗号、少引号），会导致后续所有composer命令直接崩溃，报file_get_contents(): Failed to open stream或JSON decode error - 旧版 Composer（如 1.x）不支持 HTTPS 镜像，卡在
Loading composer repositories...—— 升级到composer self-update至 2.5+ 可解决 - 用了代理或公司防火墙，HTTPS 被拦截，可临时降级为
http://mirrors.aliyun.com/composer/（仅限内网可信环境）
项目级配置比全局更可控，尤其适合 CI 和协作场景
全局配置看似省事，但容易引发包 hash 不一致、依赖解析失败等问题——比如你在 CI 流水线里混用了不同镜像，或开源项目要求走官方源测试新发布逻辑。
项目级配置写进 composer.json，所有人行为一致：
- 进项目根目录，运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 该命令自动在
composer.json顶层写入"repositories"字段，key必须是"packagist"，不能是"aliyun"或其他别名 - 如果项目已有
"repositories"，别手动覆盖——用命令追加，否则可能误删私有包源 - 换源后首次
composer install若报 hash 校验失败，删掉vendor和composer.lock重来即可
镜像只加速下载，不解决依赖解析慢的问题
如果 composer update 卡在 Resolving dependencies 几十秒甚至几分钟，和镜像源毫无关系。
这是本地环境或 composer.json 写法导致的，比如：
- 锁文件里有冲突约束（
^2.0和~1.8同时存在） - 启用了
prefer-stable: false或大量dev-分支依赖 - PHP 版本声明太宽泛（如
"php": "^7.4 || ^8.0"），让解析器穷举组合
这时候换镜像、清缓存、重装 Composer 都没用——得去调 composer.json 的约束逻辑，或者升级到 Composer 2.9.6（它改进了依赖解析算法，对大型项目提速明显）。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
