根本原因是php加载的ca证书包过旧,无法验证isrg root x1/x2等现代https证书;需运行php -r "print_r(openssl_get_cert_locations());"确认default_cert_file和ini_cafile路径,下载curl.se最新cacert.pem并统一配置php.ini中curl.cainfo与openssl.cafile为同一绝对路径,重启php环境后生效。

根本问题不是镜像站证书过期,而是你本地 PHP 加载的 CA 证书包太旧,无法验证当前主流 HTTPS 证书(比如 ISRG Root X1/X2)。
确认 PHP 实际使用的 CA 证书路径
别靠猜或翻文档,让 PHP 自己说清楚它在用哪个证书文件:
运行 php -r "print_r(openssl_get_cert_locations());",重点看两行:
-
default_cert_file:PHP 默认尝试读的路径,如果为空或指向一个 2022 年前的文件,基本就是根因 -
ini_cafile:来自php.ini的显式配置,如果这行是空的,说明你没配,或配错了路径
Windows 常见失效路径:C:/phpEnv/php/extras/ssl/cacert.pem;Linux/macOS 常见路径:/etc/ssl/certs/ca-certificates.crt 或 /usr/local/etc/openssl/cert.pem
下载并统一配置最新 cacert.pem
必须用 curl.se 官方维护的证书包。XAMPP/WAMP/phpEnv 自带的 curl-ca-bundle.crt 多数停更于 2021 年,已无法验证现代证书链:
下载命令(Linux/macOS):curl -sS https://curl.se/ca/cacert.pem -o /usr/local/etc/php/cacert.pem
下载命令(Windows):curl -sS https://curl.se/ca/cacert.pem -o C:/phpEnv/php/extras/ssl/cacert.pem
然后在 php.ini 中**同时且严格一致地**设置:
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论(Discussion)”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性,以及撰写结论。当用户输入以下任一指令时也会自动触发该功能: - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
curl.cainfo="/usr/local/etc/php/cacert.pem"(Linux/macOS)或curl.cainfo="C:/phpEnv/php/extras/ssl/cacert.pem"(Windows) -
openssl.cafile="/usr/local/etc/php/cacert.pem"(Linux/macOS)或openssl.cafile="C:/phpEnv/php/extras/ssl/cacert.pem"(Windows)
注意:路径必须是绝对路径、正斜杠(或 Windows 双反斜杠)、英文双引号包裹;改完后 CLI 模式需新开终端,Web 模式必须重启 Apache/Nginx/PHP-FPM,仅重载配置无效
验证是否真为证书问题,而非镜像不可用
很多报错看着像证书失败,其实是镜像本身挂了或 DNS 解析异常:
手动测试镜像连通性:curl -v https://mirrors.aliyun.com/composer/packages.json
如果返回 HTTP/2 200 且没有 SSL certificate problem 提示,说明镜像端正常,问题一定在你本地证书或 PHP 配置
检查当前全局镜像:composer config -g repo.packagist,输出应为 https://mirrors.aliyun.com/composer/(注意是 HTTPS,阿里云已停用 HTTP);若为空或仍是 https://packagist.org,先执行:composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
为什么不要直接禁用 TLS?
临时加 COMPOSER_DISABLE_TLS=1 composer install 或设 disable-tls true 确实能绕过报错,但这是把安全门拆了去修锁——镜像站若被劫持,你拉下来的包可能已被篡改。
这种做法只应在 CI 构建卡死、且你**100% 确认镜像域名可信、网络链路干净**时用一两次;生产环境、团队协作项目中,它比证书错误本身更危险。
真正要盯住的,是 php.ini 里那两行路径是否真实存在、是否最新、是否被两个扩展同时加载——这才是每次 composer diagnose 报 TLS 错误时,最常被跳过的一步。










