composer config -g repo.packagist 命令没生效是因为三个硬性条件未同时满足：键名必须为单数小写repo.packagist、第三个参数composer是必填type值、url必须以/结尾；任一不符均静默回退官方源。
composer config -g repo.packagist 命令为什么没生效
不是命令输错了，而是三个地方中任意一个不满足，就会静默失败、不报错、也不走镜像——你看着命令回显“success”，实际还是连 packagist.org。
-
repo.packagist必须是单数、全小写、不能多s（repos.packagist或repositories.packagist.org在 2.x 中不被识别） - 第三个参数
composer是 type 值，不是可选注释——漏掉它，Composer 会 fallback 到默认源 - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（拼出的路径变成/composerpackages.json，直接 404） - Windows 下用 Git Bash 时，
COMPOSER_HOME可能未生效，实际配置写入的是%APPDATA%\Composer\config.json，而不是~/.composer/config.json
全局换源和项目级换源哪个更靠谱
全局配置（composer config -g）适合个人开发机，但 CI 流水线、私有包协作、多项目混用时容易翻车；项目级配置则更可控，尤其适合团队交付。
- 全局配置优先级最高，但一旦项目
composer.json里出现"repositories"字段（哪怕空数组、哪怕只写了"packagist.org": false），它就完全失效 - 项目级配置：进项目根目录，运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g），它会自动 merge 进composer.json的repositories对象里 - 如果原
composer.json里"repositories"是数组格式（如[{}]），命令会失败，必须手动改成对象格式："repositories": { "packagist": {} }才能安全 merge - 项目级配置会被 Git 跟踪，新人 clone 后
composer install自动走镜像，composer.lockhash 一致，协作更稳
换源后怎么确认真生效了
别信“命令成功”，要查三处输出是否统一指向镜像域名。
- 查配置：
composer config -g repo.packagist输出必须是类似{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，不是空、不是null、也不是packagist.org - 看诊断：
composer diagnose，找到Repo:那行，域名必须是mirrors.aliyun.com或对应镜像域名 - 抓真实请求：
composer show -p | head -1第一行应显示镜像地址；更彻底点，跑一次composer update -vvv，日志里所有Downloading行的 URL 都得含镜像域名 - 如果仍连
packagist.org，立刻删掉vendor/和composer.lock再重装——composer.lock里硬编码了旧源 URL，不会随配置自动刷新
阿里云镜像现在还可靠吗
截至 2026 年 7 月，阿里云镜像是唯一持续全量同步、HTTPS 可靠、索引完整且仍在 actively 维护的国内源。
- 腾讯云镜像偶发延迟（例如新发布的
laravel/framework v11.0.0可能晚几小时上线） - Laravel China 镜像已于 2025 年底停服，访问直接返回
404 - phpcomposer.com 已停更，触发
cURL error 60: SSL certificate problem - 华为云镜像虽提供企业级 SLA，但同步频率为 1 小时，对快速迭代项目不够友好
- 所有镜像地址必须用 HTTPS，且末尾带
/；http://开头在 Composer 2.x 中默认被禁用
