composer异常根源在php的openssl/curl层，必须使openssl.cafile与curl.cainfo指向同一最新cacert.pem文件，路径绝对、一致、可读；运行php -r "print_r(openssl_get_cert_locations());"确认实际加载路径。
直接结论：Composer 本身不管理 CA 证书，异常根源在 PHP 的 OpenSSL/cURL 层——必须更新 openssl.cafile 和 curl.cainfo 指向的 PEM 文件，且两者路径必须完全一致。
确认 PHP 当前加载的证书路径
别猜，让 PHP 自己说它在用哪个文件：
php -r "print_r(openssl_get_cert_locations());"
重点看两个字段：
-
default_cert_file：PHP 默认尝试读的路径，为空、不存在或大小为 0 就是病灶 -
ini_cafile：来自php.ini的显式配置，若和default_cert_file不一致，说明配置未生效或加载了错误的php.ini
常见失效路径包括：/etc/ssl/certs/ca-certificates.crt（旧版 Ubuntu）、C:/php/extras/ssl/cacert.pem（XAMPP 自带陈旧包）、/usr/local/etc/php/cacert.pem（Homebrew PHP 未更新）。
下载并替换为最新 cacert.pem
必须从官方源获取，不能用随意导出的证书：
- 下载地址：https://www.php.cn/link/5fe4dadcdb001d8566cd20e6d8a20251
- 保存为稳定绝对路径，例如：
/usr/local/etc/php/cacert.pem或C:/php/cacert.pem - Windows 路径中用正斜杠
/或双反斜杠\，单反斜杠会被当转义符
验证文件有效性：
openssl x509 -in /path/to/cacert.pem -text -noout
输出应以 -----BEGIN CERTIFICATE----- 开头，且无乱码或截断。
同步配置 php.ini 中的两个关键项
Composer 同时依赖 OpenSSL 和 cURL 扩展，二者各自读一个配置项，只配一个大概率仍报错：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
openssl.cafile控制 OpenSSL 层（如file_get_contents） -
curl.cainfo控制 cURL 层（Composer 默认 HTTP 客户端底层）
在 php.ini 中写入（路径必须完全一致）：
openssl.cafile="/usr/local/etc/php/cacert.pem" curl.cainfo="/usr/local/etc/php/cacert.pem"
改完后重启 CLI 环境或 Web 服务（如 php-fpm、Apache）。验证是否生效：
php -i | grep -E "(openssl.cafile|curl.cainfo)"
别被 composer config ssl.cafile 带偏
这个命令对默认源基本无效，原因有三：
- 它只影响 Composer 自封装的 HTTP 客户端（如
php-http驱动），而底层仍走系统 cURL/OpenSSL - Composer ≥2.5 版本会先尝试用该路径初始化 OpenSSL 上下文，失败则静默 fallback 到系统默认 CA，不报错也不提示
- 项目级配置（不加
--global）只改当前composer.json，其他项目或全局命令仍不生效
真正有效的做法是：
composer config --global ssl.cafile /usr/local/etc/php/cacert.pem
再确认：
composer config --global --list | grep ssl.cafile
但请注意：即使这么配了，如果 php.ini 里 openssl.cafile 和 curl.cainfo 没设对，依然会失败——CA 信任链断裂发生在 PHP 底层，不是 Composer 层能绕过的。
最常被忽略的是：证书路径写对了，但 PHP 进程没权限读（比如 www-data 用户无法访问家目录下的 .pem 文件），或者文件被编辑器加了 BOM/空行——这些细节不排查，换十次证书都没用。
