答案是95%的Composer SSL报错源于php.ini中curl.cainfo与openssl.cafile未同时配置、路径不一致或文件无效；需运行php -r "print_r(openssl_get_cert_locations());"和curl -v验证，下载最新cacert.pem并统一配置两字段为同一绝对路径，重启环境生效。
php.ini 里没配对 curl.cainfo 和 openssl.cafile
95% 的 Composer SSL 报错，根源是 PHP 底层找不到可信 CA 证书文件。不是镜像坏了，也不是你网络有问题，而是 curl.cainfo 和 openssl.cafile 这两个配置项没同时设、路径不一致、或指向的文件根本不存在。
先确认问题：运行 php -r "print_r(openssl_get_cert_locations());"，重点看 default_cert_file 和 ini_cafile 输出是否为空、路径是否存在、文件大小是否 > 0。再跑 curl -v https://packagist.org/packages.json —— 如果也报 SSL certificate problem: unable to get local issuer certificate，就坐实了是 PHP 层级证书链失效。
- 下载最新证书：
curl -sS https://curl.se/ca/cacert.pem -o /path/to/cacert.pem（Windows 推荐存到C:/php/extras/ssl/cacert.pem；macOS/Linux 推荐/usr/local/etc/php/cacert.pem） - 找到 CLI 模式下真正生效的
php.ini（用php --ini查Loaded Configuration File） - 在该
php.ini末尾加两行，路径必须绝对、一致、带双引号：curl.cainfo = "/path/to/cacert.pem"openssl.cafile = "/path/to/cacert.pem" - 改完必须关闭当前终端、新开一个（CLI 不热加载）；Web 环境需重启
php-fpm或 Apache/Nginx
composer config --global cafile 为什么总不生效
这条命令只影响 Composer 自己封装的 HTTP 客户端（基于 php-http），但实际发起 HTTPS 请求的是 PHP 的 cURL 或 OpenSSL 扩展——它压根覆盖不了 curl.cainfo 的优先级，也修不了底层 TLS 握手失败。
典型表现：执行 composer config --global cafile /path/to/cacert.pem 后，composer diagnose 显示 “CA file configured”，但 composer install 依然报错。一旦涉及 Git 克隆、插件调用、或某些直连 cURL 的操作，还是会走 PHP 原生扩展，证书路径错误照旧。
- 仅当无法修改
php.ini（如 CI 构建环境）时，可作为临时兜底 - 正确写法：
composer config -g repo.packagist.ssl.certificate-authority /etc/ssl/certs/ca-certificates.crt（注意是repo.packagist，不是repo.packagist.org） - 该配置会写入
~/.composer/auth.json，比设COMPOSER_CAFILE环境变量更稳定
还在用已停服的中文镜像源（比如 packagist.phpcomposer.com）
这类域名早在 2024 年前后就陆续停运，证书早已过期或域名解析失败。报错里出现 https://packagist.phpcomposer.com 或 https://packagist.laravel-china.org，说明你的配置还没更新。
别硬扛证书错误，直接切到仍在维护的镜像：
- 阿里云：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 腾讯云：
composer config -g repo.packagist composer https://mirrors.cloud.tencent.com/composer/ - 华为云：
composer config -g repo.packagist composer https://mirrors.huaweicloud.com/repository/php/
切完后建议运行 composer update --lock 刷新 composer.lock，避免旧锁文件仍引用 HTTPS 失效地址。
误用 COMPOSER_DISABLE_TLS=1 或 secure-http=false
这些是应急降级手段，不是解决方案。设 COMPOSER_DISABLE_TLS=1 composer install 会让 Composer 强制走 HTTP（如果镜像支持），但多数国内镜像已关闭 HTTP 回退；设 secure-http=false 更危险——它允许 Composer 从 HTTP 源拉包，中间人劫持风险极高。
仅限开发机或 CI 构建失败时快速恢复，生产环境严禁使用。且必须确认镜像域名真实可信（比如 mirrors.aliyun.com 可信，xxx-mirror.com 就得查证）。
- 临时测试镜像可用性：
curl -k --proxy "" https://mirrors.aliyun.com/composer/（-k即--insecure，--proxy ""防代理干扰） -
COMPOSER_DISABLE_TLS=1只对当前命令生效，不影响全局配置 - 改
composer.json临时用 HTTP 源（如"url": "http://mirrors.aliyun.com/composer/"）必须确认镜像真支持 HTTP，且改完后不能提交到 Git
secure-http=false 一劳永逸——这三个点叠加，才是中文环境下 Composer SSL 报错最常卡住的地方。尤其 Windows 用户容易把路径写成 C:\php\extras\ssl\cacert.pem（单反斜杠被 PHP 当转义符解析失败），这个细节翻车率极高。 
