composer diagnose 会真实发起 https 请求完成完整 tls 握手、证书链校验及域名匹配检查；失败常见于中间人代理、自签名 ca 或系统 ca 证书陈旧，需结合 curl -iv 和 php openssl 配置定位根因。
composer diagnose 会真实发起 HTTPS 请求测 TLS 握手
它不是 ping 或 DNS 解析测试，而是用 PHP 的 OpenSSL 实际连接 packagist.org（或你配置的镜像），完成完整 TLS 握手、校验证书链、检查域名匹配（Subject Alternative Name）、确认证书未过期。若失败，错误通常表现为：SSL certificate problem: unable to get local issuer certificate 或 Curl error 60。
常见干扰点：
- 公司中间人代理或自签名 CA：
composer diagnose会直接暴露该问题，而composer install -vvv可能静默降级或跳过校验 - 只测 packagist.org：默认不检查你
composer.json里自定义的私有仓库（如 Artifactory），需手动用curl -Iv https://your-repo.com/packages.json验证 - 系统 CA 证书陈旧：PHP 的
openssl.cafile指向一个过期文件，执行php -r "print_r(openssl_get_cert_locations());"查看实际路径，再确认文件最后修改时间是否早于 2023 年
如何区分是证书问题还是镜像配置问题
先运行 composer config -g repo.packagist，输出必须是合法 JSON，形如：{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}。如果输出是纯字符串、null、空对象或 https://packagist.org，说明镜像根本没生效——此时看到的 HTTPS 错误，其实是连的官方源，和镜像无关。
验证步骤：
- 执行
composer clear-cache，避免旧缓存干扰 - 跑一次
composer require monolog/monolog -vvv 2>&1 | grep "GET https"，看真实请求域名是不是镜像地址 - 若仍请求
https://packagist.org/...，立刻检查项目级composer.json是否定义了repositories字段（它优先级高于全局）
curl -Iv 是最准的底层验证手段
当 composer diagnose 报错但你怀疑是镜像站自身问题时，绕过 Composer 直接测 HTTPS 层：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
执行：curl -Iv https://mirrors.aliyun.com/composer/packages.json
重点观察三处：
- TLS 握手阶段是否出现
* SSL certificate verify ok. - 响应状态码是否为
HTTP/2 200（注意不是 HTTP/1.1） - 证书信息中
subject是否包含CN = *.mirrors.aliyun.com，且无SSL_ERROR_SYSCALL或CN mismatch
如果 curl 成功但 Composer 失败，大概率是 PHP 的 OpenSSL 配置隔离——比如 CLI 和 Web 版本 php.ini 不同，或 curl.cainfo 与 openssl.cafile 指向不一致。
离线环境下的 HTTPS 检查是伪命题
设了 COMPOSER_DISABLE_NETWORK=1 后，composer install 不再发任何 HTTPS 请求，自然不会触发证书校验。此时再看到 SSL certificate problem，说明网络没真正切断——要么环境变量没生效（PowerShell 要用 $env:COMPOSER_DISABLE_NETWORK="1"），要么残留了全局镜像配置（需 composer config --global repo.packagist false 彻底禁用）。
真正容易被忽略的是：--no-plugins 必须显式加上。某些插件（如 phpstan/extension-installer）会在安装过程中主动发起远程请求，绕过 COMPOSER_DISABLE_NETWORK 的限制。
