应运行 composer config -g --list --verbose 查看实际生效镜像，重点检查 repositories.packagist.org 或兼容别名 repo.packagist 对应的 url 值，且末尾斜杠不可省略，否则导致 404。
Composer 镜像地址不写在 composer.json 里，也不靠改 PHP 配置生效——它存于全局或项目级的 Composer 配置文件中，通过 composer config 命令读写。
怎么查当前用的是哪个镜像地址
运行这条命令就能看到实际生效的源：
composer config -g --list --verbose
输出里找 repositories.packagist.org 或 repo.packagist 这两处。前者是 Composer 2.x 默认结构，后者是旧版 alias（仍被兼容）。注意末尾斜杠不能少：https://mirrors.aliyun.com/composer/ ✅，https://mirrors.aliyun.com/composer ❌（会 404）。
常见误判点：
- 只运行
composer config -g不加--verbose，会漏掉嵌套字段，看不到url值 - 在项目目录下运行却忘了加
-g，查到的是项目局部配置，不是全局生效的那个 - 输出里看到
packagist.org，但没注意上面一行是不是repo.packagist已被重写——得看完整路径匹配
为什么换了镜像还是卡在 downloading
镜像配置成功 ≠ 下载一定变快。Composer 会绕过镜像直连 GitHub 的场景很常见：
- 依赖类型是
"type": "vcs"或指定了"source"，Composer 就调用系统git clone，走 HTTPS 或 SSH 协议，完全不经过镜像 - 包本身没发布
dist（ZIP），只有source（Git），哪怕配了镜像，也得走 Git 克隆 - 镜像站同步延迟或临时故障，返回 503 或空响应，Composer 默认不重试，直接报错
验证是否真走镜像：运行 curl -I https://mirrors.aliyun.com/composer/，必须返回 HTTP/2 200；如果超时或 503，换腾讯云镜像或暂时切回官方源 + 代理。
下载中断后重试失败，哪些操作纯属浪费时间
Composer 没有断点续传，中断后已写的临时 ZIP 文件（如 vendor/composer/tmp-xxx.zip）会被自动删除，重试就是从头开始。以下动作不仅无效，还可能让问题更糟：
- 手动修改
vendor/composer/installed.json或补全残缺内容——文件校验失败会直接拒绝加载 - 只删
vendor/却不清缓存，损坏的 ZIP 仍在~/.composer/cache/files/里，重装时立刻复用并报Corrupted zip file - 在
composer.json里加"config": {"timeout": 600}——这个字段根本不控制下载超时，真正起作用的是process-timeout（全局配置） - 反复执行
composer update十几次指望“撞对一次”——网络不稳定时，大概率连续失败，且缓存越积越多占磁盘
真正管用的三步组合拳
别只盯着“怎么续传”，重点是绕过下载环节本身：
- 先清缓存：
composer clear-cache（强制丢弃所有可能损坏的 ZIP 和元数据） - 再锁死镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（确保所有新项目都生效） - 最后加稳态参数：
composer install --prefer-dist --no-plugins --no-interaction（跳过插件干扰、强制走 ZIP、避免交互卡住）
最常被忽略的一点：Composer 的“下载失败”提示八成不是下载本身的问题，而是 DNS 解析超时或 TLS 握手失败（尤其在企业内网或代理后），此时换镜像比调任何 timeout 参数都有效。
