结论是问题出在底层HTTPS连接环节，需分镜像源、SSL校验、代理链三类排查；curl能通但Composer卡在SSL handshake failed，说明PHP OpenSSL未信任当前证书链，常见于MITM代理或Windows下cacert.pem过旧。
直接结论：这不是 Composer 自己的问题，而是底层 HTTPS 连接环节出了故障；先用 curl -v https://packagist.org/packages.json 复现，再分三类处理——镜像源、SSL 校验、代理链。
curl 能通但 composer install 卡在 SSL handshake failed
说明 PHP 的 OpenSSL 没信任你当前环境的证书链，常见于中文系统装了 Clash/Surge 等 MITM 代理，或 Windows 上 PHP 自带的 cacert.pem 过旧。
- 临时验证：清空代理变量再试，
HTTP_PROXY= HTTPS_PROXY= composer install—— 若成功，就是代理根证书没被 PHP 识别 - 查 PHP 用的证书路径：
php -r "print_r(openssl_get_cert_locations());"，重点关注default_cert_file - 若该文件为空、陈旧（修改时间早于 2022 年）或根本不存在，需手动下载最新 CA 包（如 https://www.php.cn/link/5fe4dadcdb001d8566cd20e6d8a20251），然后在
php.ini中显式设置：openssl.cafile=/path/to/cacert.pem - Windows 用户注意：PHP 安装目录下的
extras/ssl/cacert.pem很可能已失效，别依赖它
报错含 cURL error 60 / certificate verify failed
这是 OpenSSL 明确拒绝证书，不是超时也不是 DNS，和 http.timeout 无关。错误里出现 SSL routines:tls_process_server_certificate:certificate verify failed 就是典型信号。
- 先确认系统级是否正常：
curl -I https://packagist.org若同样失败，问题出在系统 CA 或网络中间设备（如企业防火墙劫持） - 别急着关 SSL：
composer config -g secure-http false不解决证书校验失败，它只控制是否允许 HTTP 源 - 真正绕过证书校验（仅限调试）：
COMPOSER_NO_SSL=1 composer install，或全局设composer config -g disable-tls true（后者更激进，会禁用全部 TLS） - 长期方案永远是更新 CA 证书 + 配置
openssl.cafile，而不是禁用安全机制
换镜像源后仍提示 packages.json 下载失败
国内用户最常卡在这一步：以为换了阿里云镜像就万事大吉，结果还是报 The "https://packagist.org/packages.json" file could not be downloaded —— 注意，这个 URL 是硬编码在 Composer 源码里的，即使你配了镜像，首次初始化仍会尝试访问官方地址。
- 必须同时配置镜像源 + 关闭对 packagist.org 的强制访问：
composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/ - 检查是否残留旧镜像：
composer config -g repo.packagist，若输出https://packagist.phpcomposer.com这类已停服地址，立刻换掉 - 某些老版本 Composer（composer self-update
- 如果镜像本身返回 502（比如用 Clash 配了
https-proxy但填成https://127.0.0.1:7890），记住：https-proxy的值必须是http://开头，否则一定失败
真正麻烦的不是某条报错，而是多个条件叠加：比如你开了代理、CA 证书又过期、还用了停服镜像源——这时候看最后一行红字毫无意义。每次执行前，先跑一遍 curl -v https://mirrors.aliyun.com/composer/packages.json，确保底层 HTTPS 能通，再让 Composer 跑，省下大量排查时间。
