直接修改php.ini中的curl.cainfo和openssl.cafile比仅配置composer的cafile更可靠，因后者只影响composer自身http请求，不控制php底层函数及第三方下载器；相对路径、反斜杠解析失败、权限问题或php cli/web配置分离均会导致composer config -g cafile失效。
直接改 php.ini 里的 curl.cainfo 和 openssl.cafile，比只配 Composer 的 cafile 更可靠；否则部分依赖安装或插件调用仍会失败。
为什么 composer config -g cafile 经常不生效
这个命令只影响 Composer 自己封装的 HTTP 请求，不控制 PHP 底层的 file_get_contents()、stream_context_create() 或某些第三方下载器。常见失效场景：
-
cafile值是相对路径（如./cacert.pem），Composer 会静默忽略 - 路径用了单反斜杠
C:phpcacert.pem，JSON 解析失败，实际写入的是空字符串 - 配置写入了
~/.composer/config.json，但当前用户无读权限（比如被 root 写过） - PHP CLI 和 Web SAPI 加载的是不同
php.ini，而你只改了其中一个
怎么确认 PHP 真正读到了证书路径
别信 composer diagnose 输出的 “CA file: …”，它只反映 Composer 自己的配置。运行这行命令看 PHP 底层是否认账：
php -r "print_r(openssl_get_cert_locations());"
重点检查输出里的 default_cert_file 和 ini_cafile 字段：
- 如果都是空、
false或指向一个不存在的路径，说明 PHP 根本没加载到证书 - 如果路径存在但文件不可读（
ls -l /path/to/cacert.pem权限为 000），也会验证失败 - Windows 下常见
default_cert_file指向C:phpextrassslcurl-ca-bundle.crt，但该文件压根没下载
必须同时设 curl.cainfo 和 openssl.cafile
Composer 底层主要走 cURL，所以 curl.cainfo 优先级更高；但某些扩展或函数（比如 openssl_x509_parse()）会 fallback 到 openssl.cafile。两者都设才保险：
- 下载最新
cacert.pem：从 https://www.php.cn/link/5fe4dadcdb001d8566cd20e6d8a20251 保存为绝对路径（如/etc/ssl/certs/cacert.pem） - 编辑 CLI 模式下真正生效的
php.ini（执行php --ini确认 Loaded Configuration File） - 添加两行（路径必须是绝对路径，带双引号）：
curl.cainfo="/etc/ssl/certs/cacert.pem"<br>openssl.cafile="/etc/ssl/certs/cacert.pem"
- 关掉当前终端，新开一个——CLI 下不需要重启 Apache/Nginx，但必须重载 PHP 配置上下文
Windows 路径和多 php.ini 的坑
Windows 用户最容易栽在这两个地方：
- 路径写成
C:phpcacert.pem，没加引号也没转义，在php.ini里会被解析成控制字符；正确写法是curl.cainfo="C:/php/cacert.pem"或curl.cainfo="C:\php\cacert.pem" - WAMP/XAMPP 通常有两套
php.ini：一套给 Apache（apache/bin/php.ini），一套给 CLI（php/php.ini）。务必确认你改的是php --ini显示的那个 - 如果用的是 Docker，光改宿主机
php.ini没用，容器内还得装ca-certificates包并同步证书路径
真正起效的关键不是“有没有配”，而是“PHP 进程启动时有没有把那个路径加载进内存”。很多问题反复出现，是因为改完 php.ini 没关终端，或者根本没确认 CLI 和 Web 是否共用同一份配置。
