Composer中文镜像与Composer自动填充配置

千万别小看这条命令——composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，三个参数缺一不可，漏掉任何一个都会静默失效，而且不报错。

composer config -g repo.packagist 命令必须带齐三个参数

这条命令可不是“差不多就行”——漏掉任意一个参数，它都会静默失败，而且不给你任何提示。具体来说，composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 必须严格包含三部分：

• -g：全局配置，影响所有项目。漏掉它，就只改了当前目录的 composer.json，换个项目还得重新配。
• repo.packagist：键名必须是单数 repo，写成 repos.packagist 或 mirror 都不行——Composer 内部硬编码只认这个 key，写错了会悄悄写进无效字段。
• composer：这是 type 值，不是可选参数，也不是注释。省略后，Composer 2.0+ 会 fallback 到官方源，等于白配。
• https://mirrors.aliyun.com/composer/：URL 必须用 HTTPS，且末尾必须带 /。少斜杠会导致请求路径拼成 /composerpackages.json，直接 404。

验证是否真的生效，别信命令输出

执行完命令后，可别只看终端回显“OK”就以为万事大吉了。真正判断的依据只有一条：

运行 composer config -g repo.packagist，正确输出应该像这样：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}

如果返回空、null、报错，或者输出里没有 type 和 url 字段，说明没写对。

Windows 用户要特别注意，改完配置后必须重启终端才能读到新配置。CI 流水线里如果用了 sudo composer config -g，可能写进了 root 用户的配置，但构建时用的是普通用户，根本读不到。

项目级配置比全局更可靠，尤其适合协作

全局配置看着省事，但实际用起来坑不少：

• 某些项目在 composer.json 里写了 "packagist.org": false 或空 "repositories" 数组，直接屏蔽全局设置。
• 团队协作时，全局配置无法被 Git 跟踪，新人拉代码后行为不一致。
• CI 流水线混用不同镜像，可能导致 composer.lock hash 不一致，引发部署失败。

推荐做法：进项目根目录，运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉 -g）。它会自动在 composer.json 顶层写入 "repositories" 字段，key 固定为 "packagist"，不会覆盖已有私有源——前提是原来 repositories 是对象结构（不是数组）。

换源后卡在 Resolving dependencies？和镜像无关

镜像只加速下载，不解决依赖解析慢的问题。如果你发现 composer update 卡在 Resolving dependencies 几十秒甚至几分钟，那基本可以确定是本地环境或 composer.json 写法导致的：

• PHP 版本约束太宽，比如 "php": "^7.4 || ^8.0"，会让 Composer 尝试大量组合。
• 大量未锁定版本的 dev 包，如 "monolog/monolog": "dev-main"。
• require-dev 里塞了太多工具链（phpunit、phpstan、psalm 混在一起）。

这时候换镜像源毫无作用，得去调 composer.json 或升级 PHP 版本约束。