composer diagnose 检查php版本、openssl/zip/phar等关键扩展是否加载且可用、https网络连通性及tls配置；它不验证扩展功能完整性，故install时可能因底层依赖问题报错。
composer diagnose 会检查哪些系统要求
composer diagnose 是最直接的验证入口，但它不只看 PHP 版本，还会主动探测关键扩展是否加载、openssl 是否可用、zip 扩展能否解压、phar 是否支持写入等。它甚至会尝试访问 https://repo.packagist.org（默认源）来确认网络和 TLS 配置是否正常。
常见错误现象包括：
-
PHP Warning: Module 'openssl' is already loaded—— 不是缺失，而是重复加载导致冲突 -
The openssl extension is missing, which will reduce security—— 缺失openssl，composer install可能卡在包签名验证 -
The zip extension is missing, which will reduce performance—— 没有zip，Composer 会退回到慢速的纯 PHP 解压逻辑
php -m 和 composer diagnose 结果不一致怎么办
根本原因是：CLI 和 Web SAPI 的 PHP 配置文件（php.ini）往往不同。你运行 php -m 看到的是 CLI 模式下的扩展列表，而 Composer 运行时用的就是这个环境；但如果你在浏览器里跑 phpinfo()，看到的可能是 Apache 或 FPM 加载的另一套配置。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 先确认 Composer 用的是哪个 PHP：
which php或composer --version输出里的 PHP 路径 - 查它实际加载的
php.ini：php --ini - 检查该
php.ini里是否有extension=openssl、extension=zip等行，且未被注释 - Linux 下常见坑：Debian/Ubuntu 安装了
php-zip包，但 CLI 模式没启用 —— 需运行phpenmod zip
为什么 composer install 时才报扩展缺失，diagnose 却通过
composer diagnose 默认只做轻量检测，比如只检查扩展是否存在，不验证其功能是否完整。而 composer install 会真正调用 openssl_verify()、ZipArchive::open() 等函数，这时才发现扩展虽加载，但底层依赖（如 libssl 版本太旧）导致函数调用失败。
典型表现：
-
composer diagnose显示opensslOK，但install报error:060800A3:digital envelope routines:EVP_DigestInit_ex:disabled for fips -
zip扩展存在，但ZipArchive::open()返回false—— 常见于容器中缺少libzip库或权限问题 - 某些扩展（如
mbstring）虽已加载，但mbstring.func_overload被设为 7，会导致 Composer 内部字符串处理异常
CI 环境下快速验证 PHP 扩展是否就绪
别依赖交互式命令，用一行脚本判断关键扩展是否可被 Composer 安全使用：
php -r "exit(extension_loaded('openssl') && extension_loaded('zip') && extension_loaded('curl') ? 0 : 1);" \
&& echo "✅ extensions OK" \
|| echo "❌ missing required extension"
注意点：
-
curl虽非 Composer 硬性依赖（可用stream回退），但缺它会导致下载极慢或超时，CI 中务必检查 - Windows 上
php -m输出含乱码？改用php --modules更可靠 - Docker 构建时，
docker-php-ext-enable后必须重启 PHP CLI 配置缓存（如docker-php-source delete+docker-php-ext-install组合更稳）
最常被忽略的是：扩展存在 ≠ 函数可用。有些扩展（如 gd）只在特定编译选项下才提供全部 API，而 Composer 某些插件会悄悄调用它们。真要保险，得在 CI 里跑一次最小 composer install 测试。
