composer diagnose 能暴露绝大多数网络与配置问题，报 WARNING 或 FAIL 即表明 composer install 不可靠；加 -v 或 -vvv 可查看检测细节及底层 HTTP 请求，精准定位 CA 文件缺失、代理超时或镜像 URL 错误等根源。
composer diagnose 不是万能诊断仪，但它能暴露绝大多数 Composer 网络与配置问题的根源。只要它报 WARNING 或 FAIL，就说明当前环境无法可靠执行 composer install —— 别跳过这步直接重装或改配置。
怎么用 -v 和 -vvv 看清每一步在做什么
默认输出太简略，容易漏掉关键失败点。composer diagnose -v 会逐项列出检测过程，composer diagnose -vvv 还会打印底层 HTTP 请求细节（比如用了哪个 CA 路径、是否走代理）。
- 看到
Checking CA file后提示not found，说明 PHP 找不到证书文件，得查openssl_get_cert_locations()返回的default_cert_file路径是否存在 - 如果
Checking HTTP connectivity卡住超过 10 秒，大概率是代理没响应或镜像 URL 末尾缺/导致 404 -
-vvv下能看到实际请求的 URL，比如GET https://mirrors.aliyun.com/composer/packages.json—— 这个地址必须和composer config -g repo.packagist输出一致
为什么 diagnose 显示 OK，但 install 还是连不上私有 HTTPS 仓库
composer diagnose 只测 packagist.org 或你当前配置的全局镜像源，完全不扫描 composer.json 里 repositories 字段定义的私有 HTTPS 地址。
- 私有 Artifactory/Nexus 源的证书信任、SNI、Token 认证等问题，
diagnose一概不检查 - 想验证私有源，得手动 curl 元数据接口：
curl -Iv https://your-repo.com/api/composer/packagist.org/packages.json，重点看* SSL connection using TLS_和HTTP/2 200 - 如果
diagnose成功但composer install卡在Loading composer repositories，八成是私有源 TLS 握手失败，不是网络不通
看到 “SSL certificate problem” 别急着关验证
这个错误不是让你加 --no-verify，而是提示证书链校验环节出问题。真实原因往往藏在三处：
- PHP 的 OpenSSL 用的 CA 文件路径和系统不一致：运行
php -r "print_r(openssl_get_cert_locations());"，确认default_cert_file存在且可读 - 镜像 URL 写错：腾讯云镜像写成
https://mirrors.cloud.tencent.com/composer（缺末尾/）会导致 404，diagnose报的也是 SSL 错误（因为返回 HTML 页面而非 JSON，证书域名不匹配） - 代理配置干扰：环境变量
HTTPS_PROXY设了但代理服务没开，diagnose会卡在 CONNECT 阶段，日志里可能只显示超时，实际是代理层拒绝连接
诊断通过但 install 还是慢或失败？注意缓存和配置覆盖
composer diagnose 通过，只代表“此刻能连上当前源”，不代表后续操作一定成功。最容易被忽略的是缓存残留和配置优先级。
- 换镜像后没跑
composer clear-cache，install仍从旧缓存读元数据，可能拉到已下线的包地址 - 项目根目录
composer.json里写了"repositories"，它的优先级高于全局config -g，diagnose查的是全局源，但install走的是项目级源 -
COMPOSER_REPO_PACKAGIST环境变量会强制覆盖所有配置，diagnose不读这个变量，所以它显示 OK，实际请求却发往别处
真正难处理的不是 diagnose 报错，而是它显示 OK 却在后续命令中失效——这时候要盯住 composer install -vvv 日志里的第一个 Downloading 行，那里才是真实生效的源地址。
