不能靠配置非 https 镜像源绕过 composer ssl 报错——secure-http=false 或 disable-tls=true 已基本失效，packagist.org 及国内主流镜像均强制 https，http 镜像源大多停服或重定向失败；真正需同步配置 curl.cainfo、openssl.cafile 和 composer_cafile 指向同一有效 ca 证书文件。
不能靠配置非 HTTPS 镜像源绕过 Composer SSL 报错——secure-http=false 或 disable-tls=true 在当前（2026年）基本失效，且会直接导致 Connection refused 或重定向失败。
packagist.org 已强制 HTTPS，HTTP 镜像源大多停服或不可用
自 2024 年起，packagist.org 不再响应 HTTP 请求；国内主流镜像（如阿里云、腾讯云、清华）也仅提供 HTTPS 接口。运行 composer config -g repo.packagist composer http://mirrors.aliyun.com/composer/ 后执行 composer install，实际会收到 301 重定向或连接拒绝，根本走不到下载环节。
常见失效镜像示例：
-
http://packagist.phpcomposer.com—— 域名已停服，DNS 解析失败 -
http://packagist.laravel-china.org—— 服务下线，返回 404 - 任何以
http://开头的全局配置，都会被 Composer 2.9.6+ 主动拦截并报错
为什么 secure-http=false 看似“生效”实则掩盖问题
这个配置不是跳过证书验证，而是允许 Composer 尝试从 HTTP 源读取 packages.json 元数据——但 packagist 官方和所有活跃镜像都不提供 HTTP 元数据接口。结果是：
- Composer 会先发 HTTP 请求，被服务器 301 重定向到 HTTPS
- 重定向后仍需走 TLS 握手，底层证书问题照常暴露
- 最终报错变成
cURL error 60或SSL certificate problem: unable to get local issuer certificate，和没设一样
它唯一能“成功”的场景，是本地搭了完全离线的 HTTP 仓库（比如 http://localhost:8080），且所有包都提前放好——这不属于常规开发环境。
真正该检查的三个路径，一个都不能少
Composer 的 HTTPS 请求由 PHP 的 cURL 扩展发起，而 cURL 依赖两个独立配置项，缺一不可：
-
curl.cainfo：cURL 自己查证书链时用的 PEM 文件路径 -
openssl.cafile：PHP OpenSSL 扩展校验证书时用的 PEM 文件路径 -
COMPOSER_CAFILE：Composer 自封装 HTTP 客户端（php-http）用的路径，优先级最低
必须同时满足：
- 三者指向同一个文件（推荐用 https://www.php.cn/link/5fe4dadcdb001d8566cd20e6d8a20251 下载的最新版）
- 路径为绝对路径，Windows 用
"C:/php/extras/ssl/cacert.pem"，不用单反斜杠 - 修改的是 CLI 模式下
php --ini显示的 php.ini，不是 Apache 或 fpm 的那一份 - 改完关闭终端重开，否则
php -r "print_r(openssl_get_cert_locations());"仍显示旧值
验证是否真修好了，只看这两行命令
别等 composer install 跑完才判断——它中间可能卡在 Git 克隆或插件调用，那些环节不走 Composer 的 cafile 配置。
直接验证底层能力：
-
php -r "echo file_get_contents('https://packagist.org/packages.json?_t=' . time());"—— 不报错且输出 JSON，说明 PHP 层 TLS 通了 -
curl -v https://packagist.org/packages.json 2>&1 | grep "successfully received"—— 确认系统 curl 和 PHP cURL 用的是同一套证书信任链
如果第一行成功、第二行失败，说明 curl.cainfo 和 openssl.cafile 没配一致；如果都失败，说明文件路径错、权限不足，或系统时间偏差超 5 分钟。
