composer config -g repo.packagist 易静默失效，因必须同时满足：键名严格为单数repo.packagist、中间参数composer为必填type值、url须https且末尾带/；任一缺失即回退官方源，验证需composer config -g repo.packagist输出完整json。
直接配 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就能解决 90% 的下载卡顿问题，但这条命令极易静默失效——不报错、不提示，composer install 照样连 https://packagist.org，你根本不知道它没生效。
为什么 composer config -g repo.packagist 总是“看起来成功，实际没用”
Composer 对这条命令的校验非常严格，漏掉任意一个要素都会直接 fallback 到官方源，且完全不提醒：
-
repo.packagist必须是单数、全小写；写成repos.packagist或repositories.packagist，配置就被彻底忽略 - 中间的
composer是type值，不是可选参数，也不是占位符；漏掉它，Composer 2.x 会当作无效配置丢弃 -
URL必须以https://开头，且末尾必须带/；https://mirrors.aliyun.com/composer❌ 会拼出/composerpackages.json导致 404 - Windows 用户执行完需重启终端；Linux/macOS 下若用
sudo composer config -g，配置写进了/root/.composer/config.json，普通用户运行时读不到
验证镜像是否真生效，别信 composer config -g 输出
composer config -g repo.packagist 只告诉你“你写了什么”，不等于 Composer 正在用它。真正生效要看网络请求：
- 先清缓存：
composer clear-cache - 再跑一次真实操作：
composer require monolog/monolog -vvv - 在日志里搜索
Downloading，确认出现的是https://mirrors.aliyun.com/composer/packages.json - 如果看到
https://packagist.org/packages.json或https://repo.packagist.org/packages.json，说明被项目级composer.json中的repositories覆盖了 - 更可靠的验证方式：
composer diagnose，看Repo packagist.org:行显示的 URL
项目级配置比全局更可靠，尤其在 CI/CD 和 Docker 中
全局配置在宝塔、Docker 构建、GitHub Actions 等场景下极易失效：基础镜像可能没初始化 ~/.composer 目录，或执行用户（如 www）读不到 root 的配置。推荐改用项目级配置：
- 进项目根目录，运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g） - 该命令会自动向
composer.json的repositories字段追加"packagist"条目，不覆盖已有私有源 - 确保
composer.json顶层的repositories是对象（{}），不是数组（[]）；如果是数组，命令会失败 - Composer 2.2+ 要求禁用默认源：必须显式写
"packagist.org": false作为repositories数组的第一项 - 提交
composer.json到 Git，所有协作者和 CI 流水线行为一致
最常被忽略的一点：换源后仍卡在 Loading composer repositories，往往不是镜像没生效，而是旧缓存或 composer.lock 里记录的老地址还在起作用——必须先 clear-cache，再删 vendor 和 composer.lock，最后用 -vvv 重装才能看到真实请求路径。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
