必须用 repositories.packagist.org 键名、项目级 repositories 字段会完全覆盖全局配置、windows 下 git bash 可能读错配置路径；三者任一出错均导致静默失效。
composer config -g 配置没生效的三个硬伤
执行 composer config -g repo.packagist https://mirrors.aliyun.com/composer/ 看似成功，但 composer install 仍走 packagist.org，大概率是以下其一：
- 键名错：Composer 2.2+ 必须用
repositories.packagist.org，写成repo.packagist或repos.packagist会静默忽略 - 被覆盖：项目根目录
composer.json里只要存在"repositories"字段（哪怕空数组{}），全局配置就彻底失效 - 路径错：Windows 下 Git Bash 可能读
%APPDATA%\Composer\config.json，而你改的是~/.composer/config.json
验证方式不是看命令是否报错，而是运行 composer config -g repositories.packagist.org —— 输出必须是完整 JSON 对象，且 url 值带结尾 /。
项目级 repositories 字段会完全屏蔽全局镜像
这是最常被忽略的优先级陷阱。Composer 的源解析顺序是：项目级 repositories > 环境变量 COMPOSER_REPO_PACKAGIST > 全局配置。哪怕你只在 composer.json 里写了这一行：
"repositories": []
它也会让所有全局镜像设置归零。检查方法：
- 运行
grep -A 5 '"repositories"' ./composer.json - 若存在，且 URL 不以
/结尾（如"https://mirrors.aliyun.com/composer"），就会触发 404 - 临时禁用：执行
composer config --unset repositories（不加-g），再试composer install
clear-cache 不等于刷新元数据，--refresh 才是正解
composer clear-cache 只删 ~/.composer/cache/files/ 和 repo/ 下的 ZIP 包与旧 packages.json，但它不强制重拉远程元数据——下次 update 仍可能复用缓存中过期的 packages.json（默认 15 分钟不过期）。
- Composer ≥ 2.5：直接用
composer update --refresh，它丢弃所有已缓存的packages.json，只从当前生效镜像源重新下载元数据 - Composer ≤ 2.4：只能手动删对应 repo 缓存路径，例如：
rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer - 别信
clear-cache日志里 “Cache directory cleared” 就万事大吉——它清的是本地文件，不是逻辑判断
验证镜像是否真在用，得看网络请求，不是看配置输出
composer config 显示正确 ≠ 实际请求走对地址。真正有效的验证必须落到真实 HTTP 行为上：
- 加
-vvv跑一次composer install，滚动日志找Downloading行，URL 必须含mirrors.aliyun.com或你配的域名 - 更准的方法：运行
composer show -p | head -3，第一行显示的源域名应是你刚设的镜像 - 终极确认：用
strace -etrace=network composer install 2>&1 | grep 'connect'（Linux/macOS），看到连接 IP 是镜像站的才作数
很多问题卡在 TLS 或 DNS 层，比如企业网络拦截非标准证书、清华源返回人机验证 HTML 页面——这些都不会报错，但会让 Composer 解析失败。抓到真实请求路径，才能分清是配置问题，还是网络或镜像本身异常。
