composer config -g repo.packagist 命令总不生效的根本原因是三个硬性条件缺一不可：键名必须为单数 repo.packagist、type 值必须显式写 composer、url 必须是 https 且末尾带 /；任一缺失即静默回退官方源，验证需输出完整 json 对象。
composer config -g repo.packagist 命令为什么总不生效
根本原因不是网络差，而是三个硬性条件缺一不可：repo.packagist（不能写成 repos.packagist）、中间的 composer（这是 type 值，不是域名或可选参数）、URL 必须是 HTTPS 且末尾带 /。漏掉斜杠会拼出 /composerpackages.json 导致 404；写成 HTTP 则被 Composer 2.0+ 默认拦截。
验证是否真写入：运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null 或报错，说明没成功。
- 常见误操作：在项目目录下执行带
-g的命令，却误以为只影响当前项目 - 多用户环境（如宝塔）中，
root下配了镜像，但 Web 进程以www用户运行，配置文件互不可见 - CI 容器未初始化
~/.composer目录，命令静默失败，根本没写入任何配置
项目级 repositories 配置为何优先级更高且更可靠
只要项目 composer.json 里有 repositories 字段，全局配置就完全被忽略——不是“优先级低”，而是直接不读。Composer 不合并，只替换。
项目级配置写进 composer.json，Git 提交后所有协作者和 CI 环境行为一致，这才是真正可控的方式。
-
repositories必须是对象{}，不是数组[]；已有数组时，composer config repo.packagist会直接报错 - 键名必须是
"packagist"（单数），不能是"aliyun"或其他别名 - 若已有
"packagist.org": false，得先删掉，否则镜像会被屏蔽 - 改完必须运行
composer update --lock，否则composer.lock仍指向旧源地址
阿里云、腾讯云、华为云镜像的实际差异在哪
三家都同步 packagist.org，但同步策略、CDN 覆盖和存储结构不同，直接影响 composer update 速度和稳定性。
- 阿里云（
https://mirrors.aliyun.com/composer/）：同步延迟约 5–10 分钟，华北节点快，华东偶发 502；适合日常开发，不推荐高频更新依赖的 CI 场景 - 腾讯云（
https://mirrors.cloud.tencent.com/composer/）：CDN 覆盖广，南方用户稳定，但不保留已删包；遇到Package not found可能是原包被作者下架，非镜像问题 - 华为云（
https://mirrors.huaweicloud.com/repository/php/）：全量镜像含历史版本，同步延迟最低，但 metadata 请求略慢（因分片存储）
测试方法很简单：清缓存后跑 time composer update --dry-run，重点看是否出现 Connection refused 或 SSL certificate problem——后者多因镜像用了自签名证书或过期中间证书。
换源后 vendor 和 composer.lock 为什么必须删干净
镜像只加速元数据（packages.json、p2/xxx.json）获取，不干预 dist 文件下载路径。而 composer.lock 里记录的是旧源的 hash 和 URL，哪怕你已经切到阿里云，它仍可能尝试从 packagist.org 下载并校验失败。
- 必须先运行
composer clear-cache - 手动删掉项目下的
vendor/和composer.lock - 再执行
composer install -vvv，观察日志是否出现新镜像域名（如mirrors.aliyun.com） - 若仍卡在
Loading composer repositories，大概率是 DNS 解析慢，可试--no-plugins排查插件干扰
镜像不是魔法，它只管元数据同步；如果某个包实际托管在 GitHub 私有仓库，那部分流量依然走原始 VCS 配置，和镜像无关——这时候该检查的是 SSH key 或 PAT 权限。
