composer config -g repo.packagist 静默失效主因是键名错（应为单数）、缺type值“composer”、URL末尾无/，三者任一出错即回退官方源；验证须输出完整JSON且日志中GET请求指向镜像域名。
composer config -g repo.packagist 这条命令必须写对，否则镜像根本不会生效——不是慢，是压根没走镜像。
为什么 composer config -g repo.packagist 总是静默失效
90% 的“配了还是卡在 Downloading”都源于命令敲错三个硬性点：
• 键名写成 repos.packagist（多一个 s），Composer 完全忽略，不报错也不提示
• 漏掉中间的 composer 参数，即没声明仓库类型，命令看似执行成功，实际 fallback 到官方源
• URL 缺少末尾斜杠，比如 https://mirrors.aliyun.com/composer ❌，会导致路径拼接错误（如请求 /packages.json 时变成 /composerpackages.json），返回 404 或空响应
验证镜像是否真生效，别只看命令有没有报错
执行完配置命令后，必须立刻验证：
• 运行 composer config -g repo.packagist
• 正确输出应为完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}（旧版）或纯 URL 字符串（新版）
• 如果输出为空、null、Key does not exist，或仍是 https://packagist.org，说明没写进去
• 更进一步：加 -vvv 跑一次 composer install -vvv，盯住日志里第一行 GET 请求地址——必须是镜像域名（如 GET https://mirrors.aliyun.com/composer/packages.json），而不是 packagist.org
宝塔、Docker、CI 环境里全局配置为啥不起作用
全局配置写在当前用户的 ~/.composer/config.json，但实际运行环境往往不是你当前登录的用户：
• 宝塔「一键部署」默认以 www 用户执行，root 下配的配置它读不到
• GitHub Actions runner、GitLab CI job、Docker 容器里的 composer 命令通常跑在非 root 用户下
• systemd 服务或定时任务也常指定独立用户
解决方法很直接：
• 先确认执行用户（whoami 或查日志 UID）
• 再用对应用户身份重配，例如：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
• 更稳妥的做法是改用项目级配置，把镜像写进 composer.json，拉代码就生效，不依赖用户环境
项目级配置怎么避免清空私有源
直接执行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加 -g）会自动合并，但前提是 composer.json 中 repositories 是标准格式：
• 如果原本是空对象 "repositories": {}，命令会转为数组并追加 packagist 条目
• 如果原本是数组 "repositories": []，命令会向末尾插入新项
• 但如果已有自定义源（如 Git VCS 或 Satis），且 repositories 是对象而非数组，命令可能覆盖整个字段
所以更安全的做法是：
• 手动编辑 composer.json，确保 repositories 是数组
• 在其中添加：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
• 同时在根节点加 "packagist.org": false（注意：不是放在 repositories 里，而是同级字段），否则私有源和镜像共存时可能冲突
• 改完删掉 vendor/ 和 composer.lock，再跑 composer install
立即学习“PHP免费学习笔记（深入）”；
换镜像只是第一步，真正容易被忽略的是：镜像只加速元数据拉取和包下载，不解决Resolving dependencies 卡顿；而一旦 composer.lock 记录的是旧源哈希，哪怕镜像已生效，也会报 hash 不匹配——这时候删 lock 文件重装，比反复检查配置更有效。 
