composer config -g repo.packagist 输出必须是完整 JSON 对象如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null、报错或仅字符串均说明配置失败，常见错误为键名错（如 repos.packagist）、URL 缺末尾 / 或漏 composer type 值。
直接看 composer config -g repo.packagist 的输出
这个命令返回的必须是完整 JSON 对象，比如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果输出是空、null、报错 Could not find package repo.packagist in global config，或者只有一行字符串（如 https://mirrors.aliyun.com/composer），说明配置没生效或写错了键名。
常见错误包括：
• 键名写成 repos.packagist（多一个 s）或 repositories.packagist.org（新版不认）
• url 值末尾缺斜杠，如 "https://mirrors.aliyun.com/composer" → 必须是 "https://mirrors.aliyun.com/composer/"
• 漏了 "type": "composer" 字段，哪怕 URL 正确也会静默失效
用 -vvv 看真实请求地址，别信配置项
配置可能被项目级 composer.json 覆盖，也可能缓存未刷新，所以光看 config 输出不够。真正要确认的是 Composer 实际发出去的 HTTP 请求地址。
运行：
• composer -vvv require monolog/monolog
• 或 composer -vvv update --dry-run
在日志里找类似这样的行：GET https://mirrors.aliyun.com/composer/packages.json
或GET https://repo.huaweicloud.com/repository/php/packages.json
只要这个 URL 和你预期的镜像地址一致，就说明源已生效；如果还是 https://repo.packagist.org/...，那问题还在配置或缓存层。
为什么 composer diagnose 会报错但其实没问题
composer diagnose 默认检测是否能连通 https://packagist.org，并在连不上时标为 ERROR。但这在国内配了镜像的情况下是正常现象——它不是 bug，是设计如此。
关键判断点：
• 先跑 composer config repo.packagist.org，确认返回的是国内镜像地址
• 再跑 composer -vvv install，看实际请求是否命中镜像
• 如果请求成功且返回 200，diagnose 的 ERROR 可以忽略
别因为 diagnose 报红就切回官方源重试，反而可能把问题复杂化。
换源后还 404？composer.lock 在硬编码旧地址
这是最容易被跳过的环节：即使 config 对了、-vvv 显示请求走新镜像，composer install 仍可能卡在 provider 文件 404。原因在于 composer.lock 里固化了每个包的元数据下载路径，比如："https://packagist.org/p2/monolog/monolog.json"
这些地址不会随镜像配置自动更新。必须：
• 删除 vendor/
• 删除 composer.lock（只删 vendor 不够）
• 运行 composer install（不是 update）重新生成 lock 文件
CI 环境尤其要注意：如果 composer.lock 被提交进 Git，等于把旧 provider 地址钉死在流水线里，每次构建都会复现 404。
