直接用curl -I测试镜像地址是否可用，正常应返回HTTP/2 200且Content-Type: application/json；若返回302跳转、SSL错误或卡住，说明镜像不可用于自动化场景，需换源或更新CA证书。
直接用curl验证镜像地址是否可用
别等composer install跑半天才失败，先手动测镜像本身通不通。很多“404”或“SSL error”根本不是Composer的问题，而是镜像返回了HTML页面（比如人机验证）、证书过期、或URL拼错。
执行：curl -I https://mirrors.aliyun.com/composer/packages.json
- 正常应返回
HTTP/2 200，且Content-Type: application/json - 若返回
HTTP/1.1 302跳转到登录页，说明该镜像不适合自动化场景，换腾讯云或华为云源 - 若卡住或报
SSL certificate problem，说明系统CA证书太旧，需更新cacert.pem并配置openssl.cafile
加-vvv看真实请求地址，而不是信composer config输出
composer config -g repo.packagist显示的只是配置值，不代表实际生效——尤其当项目composer.json里有"repositories": []时，全局配置会被彻底忽略。
真正走哪条路，得看composer install -vvv第一行Downloading日志：
- 运行：
composer install -vvv 2>&1 | head -n 10 | grep Downloading - 第一行URL才是真实请求地址，比如
https://packagist.org/packages.json就说明没走镜像 - 如果看到
https://mirrors.aliyun.com/composer/...但依然失败，问题在缓存或元数据损坏，不是网络
删干净再重试：cache、lock、vendor三件套
Composer的缓存和锁文件会固化旧路径、旧证书、旧provider地址，不清理就反复踩坑。
-
composer clear-cache：清全局缓存；Windows用户还得手动删%LOCALAPPDATA%\Composer\cache - 删
composer.lock：它硬编码了所有包的下载地址和校验和，换源后不删它，Composer会继续按旧地址重试 - 删
vendor/：避免残留文件干扰autoload映射，尤其当你改过autoload配置后
三者缺一不可。只清缓存，composer.lock仍指向packagist.org；只删vendor，composer.lock里的旧路径还在。
用composer diagnose定位环境层问题
这个命令不解决依赖冲突，但它能快速暴露PHP环境、扩展、权限等底层缺陷，90%的“莫名其妙失败”都藏在这里。
- 报
ext-mbstring missing？立刻装：sudo apt install php-mbstring（Ubuntu）或yum install php-mbstring（CentOS） - 报
Permission denied写vendor/autoload.php？检查ls -ld vendor/，大概率是root建的目录，普通用户进不去 - 报
Connection to packagist.org failed但你配了镜像？说明项目级repositories字段覆盖了全局配置，运行composer config --unset repositories临时清除
最常被忽略的是php.ini里disable_functions禁用了file_put_contents或curl_exec——diagnose不会明说，但curl -I和php -r "echo file_put_contents('t','x');"能交叉验证。
