直接换源可解决 Composer 下载慢、超时、404 问题，但需严格满足三个硬性条件：键名必须为 repo.packagist（单数）、type 值显式设为 composer、URL 必须 HTTPS 开头且末尾带 /，且必须加 -g 才生效；项目级配置更可靠，推荐使用 composer config repo.packagist composer https://mirrors.aliyun.com/composer/。
直接换源就能解决 Composer 下载慢、超时、404 的问题，但 90% 的人配不成功——不是网络被墙，是 composer config -g repo.packagist 命令写错了三个硬性条件，Composer 会静默忽略，不报错也不提示。
为什么 composer config -g repo.packagist 总是不生效
这条命令看似简单，但漏掉任意一个要素就会白执行：
-
repo.packagist是唯一合法键名（注意是repo单数，不是repos；也不能写成packagist.org） - 中间必须显式写出
composer作为 type 值——省略后 Composer 2.0+ 会 fallback 到官方源 - URL 必须是 HTTPS 开头，且末尾带
/（少斜杠会导致请求路径变成/composerpackages.json，返回 404） - 必须加
-g：不加就只改当前项目composer.json，换目录就失效
正确写法：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
验证是否生效：composer config -g repo.packagist，应输出类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果返回空、null 或 https://packagist.org，说明没写对。
立即学习“PHP免费学习笔记（深入）”；
项目级配置比全局更可靠，尤其适合团队和 CI
全局配置看着省事，但在实际协作中容易出问题：
- 某些项目在
composer.json里写了"packagist.org": false，会直接屏蔽全局镜像 - CI 流水线常以
www或runner用户运行，而-g配的是当前登录用户的配置，权限不一致就失效 - 新人拉代码后行为不一致——全局配置无法被 Git 跟踪
推荐做法：进项目根目录，运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉 -g）。它会自动在 composer.json 顶层写入 "repositories" 字段，key 固定为 "packagist"，不会覆盖已有私有源——前提是原来 repositories 是对象结构（不是数组）。
如果项目已存在 "repositories": []（数组），别手动覆盖，用命令追加，否则可能误删私有包源。
哪些镜像地址现在还能用（2026 年 7 月实测）
截至 2026 年 7 月初，以下三个 HTTPS 镜像均支持 Composer 2.9.6，元数据同步延迟 ≤15 分钟，无 HTTP 降级风险：
-
https://mirrors.aliyun.com/composer/：华东地区响应最快，Laravel 11 / PHP 8.4 新包基本当天入库，CI 构建推荐首选 -
https://packagist.mirrors.sjtug.sjtu.edu.cn/：上海交大 SJTUG 镜像，学术网络运维，无商业干扰，适合对稳定性要求严苛的生产环境 -
https://packagist.mirrors.ustc.edu.cn/：中科大镜像，在北方和教育网环境下延迟最低，新包同步响应及时
已确认失效的地址包括：https://packagist.phpcomposer.com（404）、所有以 http:// 开头的源（Composer ≥2.2 默认拒绝）、https://packagist.jp（国内实测更慢）。
换源后仍卡在 “Resolving dependencies”？和镜像无关
镜像只加速下载，不解决依赖解析慢的问题。如果你发现 composer update 卡在 Resolving dependencies 几十秒甚至几分钟，基本可以确定是本地环境或 composer.json 写法导致的：
- PHP 版本约束太宽（如
"php": "^7.4 || ^8.0"） - 大量未锁定版本的
dev包 -
require-dev里塞了太多工具链
这类问题换任何镜像都无效，得从约束收紧、dev 包精简、lock 文件复用等方向入手。另外，改完镜像后记得删掉 vendor 和 composer.lock 再重装，否则旧 lock 文件里的 hash 可能和镜像元数据不匹配。
最易被忽略的一点：项目级 repositories 字段优先级永远高于全局配置，且不报错——你以为配好了全局镜像，其实项目里一条旧配置就把它盖掉了。
