composer diagnose 显示 ok 却装不了包，因其仅轻量检查基础连通性与权限，不校验 php 扩展启用、镜像源可用性、代理配置或真实依赖解析；加 -v 可暴露 tls/ca/http 状态等真实网络链路问题。
Composer 的 diagnose 命令能快速暴露本地环境常见配置问题，但它的输出容易被误读——它只检查基础连通性和权限，不验证 PHP 扩展兼容性或镜像源实际可用性。
运行 composer diagnose 时为什么总显示 “OK” 却仍装不了包？
这个命令默认只做轻量级检查：是否能访问 https://packagist.org、composer.json 格式是否合法、vendor/ 目录是否可写。它不会尝试下载任何真实包，也不校验 ext-curl 或 openssl 是否启用，更不会测试你配置的国内镜像（如阿里云、腾讯）是否真能响应。
- 常见假阳性：网络代理开着但未被
composer识别，diagnose仍报 OK；实际执行composer install时卡在 DNS 或 TLS 握手 - 镜像配置无效时（比如写错 URL 或已下线），
diagnose不检测，只有首次请求包时才暴露 - PHP 版本满足最低要求（如 8.1），但缺少
ext-zip，diagnose不提示，直到解压失败才报ZipArchive class not found
如何让 diagnose 检得更实在一点？
加 -v 或 --verbose 参数强制它走一遍真实网络链路，相当于模拟一次最小化 fetch：
composer diagnose -v
这时你会看到它真正尝试连接 packagist 的 API 端点，并报告 TLS 版本、CA 证书路径、HTTP 状态码。如果用了镜像，确保 composer config repo.packagist 已正确设置，否则 -v 仍走官方源。
-
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（全局镜像） - 检查
~/.composer/config.json中repositories字段是否覆盖了packagist.org - 若公司内网需代理，必须设
http-proxy和https-proxy，仅系统环境变量HTTP_PROXY不生效
diagnose 报 “The openssl extension is missing” 但 php -m | grep openssl 显示存在？
Composer 运行时用的是 CLI 版 PHP，和 Web Server（如 Apache/Nginx）加载的 php.ini 可能不同。重点查两处：
- 运行
php -i | grep "Loaded Configuration File"，确认 CLI 加载的是哪个php.ini - 该文件里
extension=openssl是否被注释（;开头）或路径错误（如 Windows 下写成extension=php_openssl.dll但 DLL 文件不存在） - 某些 Docker 镜像（如
php:8.2-cli）默认不带openssl，需手动docker-php-ext-install openssl
真正要判断 Composer 环境是否 ready，别只信 diagnose 的 OK —— 它过不了的肯定有问题，但它过了的，还得跑一次 composer create-project laravel/laravel test --no-install 看能否成功解析依赖元数据。这才是最接近真实场景的健康快筛。
