composer更新失败主因是镜像配置错误、元数据缓存未刷新及composer.lock版本锁死；换源仅加速下载，不解决依赖冲突、php不兼容或锁文件校验问题，需删vendor和lock后用install重生成。
Composer自动更新不会因换镜像源而触发，composer update 才真正拉新版本；镜像配置错误、缓存未清、composer.lock 冲突是卡顿和失败的三大主因。
为什么换了镜像源 composer update 还很慢或失败
镜像只加速下载，不解决依赖解析、PHP 版本冲突或锁文件校验问题。常见现象是卡在 Resolving dependencies... 或报 Your requirements could not be resolved。
- 先删掉
vendor/和composer.lock（确保你不需要复现旧环境） - 再运行
composer install（不是update），它会按composer.json重新解析兼容版本并生成新 lock - 如果仍失败，大概率是
composer.json里写了过严的版本约束，比如"monolog/monolog": "1.23.0"，建议改成"^1.23"或"^2.0" - 国内某些镜像凌晨同步有延迟，可临时切回官方源验证：
composer config -g repo.packagist https://packagist.org
composer config -g repo.packagist 静默失效的三个硬性条件
这条命令不是“差不多就行”，漏掉任意一个都会写入失败，且不报错——你查 composer config -g repo.packagist 时输出为空或仍是 https://packagist.org。
- 必须带
-g：缺了就只改当前项目，换目录即失效 - 键名必须是
repo.packagist（单数repo，不是repos或repositories） - URL 必须以
/结尾，且中间必须显式写composer类型值：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
项目级配置比全局更可靠，但容易清空已有私有源
进项目根目录执行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加 -g），它会直接替换 composer.json 中的 repositories 字段，不是追加。
- 如果项目原本已配私有 Git 源（如
"my-private": {"type": "vcs", "url": "https://git.example.com/pkg"}），执行后整个repositories会被清空 - 需手动编辑
composer.json，把阿里云镜像作为第一个对象写入repositories数组，并在顶层加"packagist.org": false - 改完必须删掉
vendor/和composer.lock，否则旧 lock 文件里的 dist URL 和哈希与镜像不匹配，导致校验失败
验证是否真走镜像，别信 config 输出
composer config -g repo.packagist 显示正确 ≠ 实际请求走镜像。最可靠方式是看真实 HTTP 请求日志。
- 运行
composer clear-cache && composer require monolog/monolog -vvv - 搜日志里的
GET行：出现Downloading https://mirrors.aliyun.com/composer/packages.json才算生效；若看到https://packagist.org/packages.json，说明镜像没落地 - 注意
composer diagnose输出中Repo packagist.org:后面的地址是否为你设的镜像 - CI/CD 环境下尤其要小心：全局配置写的是 root 用户，但 runner 常以
www或runner用户运行，得配对应用户的~/.composer/config.json
最容易被忽略的是：composer.lock 一旦存在，就会锁定所有包的精确版本和 dist URL，哪怕镜像已配好，它仍试图从旧路径下载 zip 包——这时候删 lock 是唯一解法，不是偷懒，是必须。
