先确认是否真证书问题：若curl -vI失败则属底层HTTPS异常；若curl成功但composer diagnose报SSL证书错误，则是PHP OpenSSL未读到有效CA证书；再排除代理干扰，检查openssl_get_cert_locations路径有效性及镜像配置是否含type和结尾斜杠。
先确认是不是真证书问题，还是网络或代理干扰
执行 curl -vI https://packagist.org/packages.json，看是否在 TLS 握手阶段就失败（比如出现 SSL routines:ssl3_read_bytes:sslv3 alert handshake failure 或卡住无响应）。如果 curl 也失败，说明不是 Composer 特有，而是底层 HTTPS 环境异常；如果 curl 成功但 composer diagnose 报 SSL certificate problem: unable to get local issuer certificate，那大概率是 PHP 的 OpenSSL 没读到有效 CA 证书。
再快速排除系统代理干扰：
Windows CMD：运行 set HTTP_PROXY= && set HTTPS_PROXY= && composer diagnose
macOS/Linux：运行 HTTP_PROXY= HTTPS_PROXY= composer diagnose
若此时通过，说明代理正在劫持 TLS 流量（比如 Clash、Surge 的 MITM 模式），但 PHP 没信任它的根证书。
检查 PHP 实际加载的 CA 证书路径是否有效
运行 php -r "print_r(openssl_get_cert_locations());"，重点关注 default_cert_file 和 ini_cafile 对应的路径。文件必须存在、可读、且最后修改时间不早于 2023 年（旧证书已无法验证主流站点）。
- Linux（Debian/Ubuntu）：
sudo apt update && sudo apt install --reinstall ca-certificates && sudo update-ca-certificates - macOS（Homebrew）：
brew reinstall ca-certificates，然后确认php.ini中openssl.cafile指向$(brew --prefix ca-certificates)/share/ca-certificates/cert.pem - Windows：下载最新
cacert.pem（来自 curl.se），并在php.ini同时设置curl.cainfo和openssl.cafile指向该文件
镜像源配置错误常被误判为证书问题
国内用户配阿里云或腾讯云镜像时，最常见错误是漏写 type 参数或 URL 缺少结尾斜杠。Composer 会静默 fallback 到官方源，然后在验证 packagist.org 证书时失败——你以为连的是镜像，其实连的是国外站。
错的写法：composer config -g repo.packagist https://mirrors.aliyun.com/composer
对的写法：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
验证是否生效：composer config -g repo.packagist，输出必须是完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
别跳过证书校验，除非你清楚后果
composer config -g secure-http false 或 --no-secure-http 只控制是否强制仓库用 HTTPS，**不绕过证书验证**；真正禁用校验要靠 COMPOSER_NO_SSL=1 或改 PHP 配置，但这会让所有 HTTPS 请求暴露于中间人攻击——哪怕你在内网，也意味着依赖包可能被篡改而无法察觉。
真正难排查的点往往不在证书本身，而在「谁在管证书」：PHP CLI 和 Web SAPI 可能加载不同 php.ini，composer diagnose 走的是 CLI 环境，而你查的可能是 Apache/Nginx 用的配置；另外某些 Windows 集成环境（如 XAMPP）自带过期的 curl-ca-bundle.crt，即使你改了 php.ini，它仍可能优先读那个陈旧文件。
