Composer连接失败：cURL error 60 或 SSL certificate problem，是因旧系统（如CentOS 6、macOS 10.12以下、PHP版本过低）缺乏最新CA证书或TLS支持所致。
Composer连接失败：cURL error 60 或 SSL certificate problem
这是 Composer 在旧系统（如 CentOS 6、macOS 10.12 以下、PHP
验证方式：php -r "print_r(stream_get_transports());" 若输出不含 tls 或 ssl，或 curl --version 显示 OpenSSL 版本低于 1.0.1，基本可确认问题根源。
- 不要手动下载 root CA 证书再配置
openssl.cafile—— 这解决的是证书校验失败，不是协议不匹配 - 不要盲目升级 Composer 自身（
composer self-update）—— 它无法绕过 PHP/cURL 的 TLS 能力限制 - 关键动作是让 PHP 的 cURL 扩展强制使用 TLS 1.2，而非依赖自动协商
在 php.ini 中强制指定 TLS 1.2（最稳定方案）
修改 PHP 配置比改 Composer 或环境变量更彻底，避免每次调用都漏配。找到你当前 CLI 模式使用的 php.ini（运行 php --ini 查看路径），在末尾追加：
[openssl] openssl.cafile=/etc/ssl/certs/ca-certificates.crt [curl] curl.cainfo=/etc/ssl/certs/ca-certificates.crt
然后重点添加这一行（必须）：
curl.options = 2048 ; CURLOPT_SSLVERSION = CURL_SSLVERSION_TLSv1_2
2048 是 cURL 常量 CURLOPT_SSLVERSION 的整数值，对应 TLS 1.2；PHP 7.0.7+ 支持直接写 CURLOPT_SSLVERSION，但低版本必须用数字。改完重启 PHP CLI 环境（无需 web 服务），再运行 composer diagnose 应显示 “The OpenSSL library is available” 且无 SSL 错误。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
临时绕过：用环境变量控制（仅限调试）
如果无法修改 php.ini（如共享主机、CI 临时任务），可用环境变量强制生效：
export COMPOSER_CAFILE="/etc/ssl/certs/ca-certificates.crt"
export PHP_INI_SCAN_DIR=""
php -d curl.cainfo=/etc/ssl/certs/ca-certificates.crt \
-d curl.options=2048 \
/usr/bin/composer install
注意两点：
-
PHP_INI_SCAN_DIR=""是为了防止其他 ini 文件覆盖你的设置 - 必须用
php -d直接传参，而不是只设环境变量 —— Composer 不读CURLOPT_SSLVERSION环境变量 - 这个方式在 Jenkins、GitLab CI 中容易因 shell 类型（sh vs bash）或子进程丢失变量而失效，不建议长期使用
为什么不用 --no-secure-http？
执行 composer config -g secure-http false 会允许 HTTP 协议源，但 Packagist.org 已全站强制 HTTPS，且 Composer 2.x 默认禁用 insecure-http 源。更重要的是，这完全没解决 TLS 协议问题 —— 即使你换到私有仓库，只要它启用 TLS 1.2+，同样会卡住。
真正要盯住的是三处：PHP 编译时链接的 OpenSSL 版本、cURL 版本、以及 PHP 运行时是否把 CURLOPT_SSLVERSION 正确透传给底层。很多用户修完 php.ini 还失败，是因为用了 phpbrew 或 asdf 切换 PHP 版本后，实际执行的不是你认为的那个 php.ini。
