composer ssl验证被跳过是安全链断裂信号，根源95%在于php.ini中openssl.cafile和curl.cainfo未正确配置有效ca证书路径，需用绝对路径指向最新cacert.pem并重启环境。
Composer 的 SSL 验证被跳过，不是“功能正常”，而是安全链断裂的明确信号——它意味着所有 HTTPS 请求（包括从 packagist.org 或私有镜像拉包）都不再校验证书，中间人攻击风险真实存在。真正要做的不是确认“是否跳过”，而是查清“为什么本该生效的验证没起作用”。
php -r "print_r(openssl_get_cert_locations());" 输出里 default_cert_file 为空或路径无效
这是 95% 的 SSL 报错根源。Composer 本身不管理证书验证，它依赖 PHP 的 OpenSSL 和 cURL 扩展；而这两个扩展靠 default_cert_file 或 ini_cafile 指定的文件做校验。如果该路径为空、指向不存在的文件、或文件权限为 000，验证必然失败，PHP 会静默降级为不校验（即“被跳过”）。
- 运行
php --ini确认 CLI 模式下真正加载的php.ini路径 - 检查输出中
default_cert_file和ini_cafile是否一致、是否存在、是否可读：php -r "var_dump(file_get_contents(ini_get('openssl.cafile')) !== false);" - Windows 常见空路径：
C:\php\extras\ssl\curl-ca-bundle.crt（但该文件根本没下载） - macOS Homebrew PHP 常见空路径：
/usr/local/etc/php/8.3/openssl.cafile（目录下无此文件） - Linux（如 Alpine）常见空链接：
/etc/ssl/certs/ca-certificates.crt→ 实际是断开的符号链接
curl.cainfo 和 openssl.cafile 没配齐或路径写错
只设 curl.cainfo 或只设 openssl.cafile 都不够。PHP 内部调用路径不统一：cURL 扩展走前者，file_get_contents("https://")、流封装器、部分 Composer 插件可能直调 OpenSSL，走后者。漏配一个，就有一类请求裸奔。
- 必须在
php.ini中同时设置两行，且都用**绝对路径**：curl.cainfo="/path/to/cacert.pem"和openssl.cafile="/path/to/cacert.pem" - Windows 路径务必加双引号：
curl.cainfo="C:\php\extras\ssl\cacert.pem"，否则反斜杠会被解析为转义 - 别用
~或相对路径，PHP CLI 不展开~，./cacert.pem会按当前工作目录找，不可控 - 证书文件必须是 Mozilla 官方维护的最新版：https://www.php.cn/link/5fe4dadcdb001d8566cd20e6d8a20251（2026 年持续更新），别用系统自带旧包
COMPOSER_CAFILE 或 composer config --global cafile 生效但验证仍被跳过
COMPOSER_CAFILE 环境变量和 composer config --global cafile 只影响 Composer 自己封装的 HTTP 客户端（基于 php-http），完全不控制 PHP 底层的 cURL 或 OpenSSL 行为。如果你看到 composer diagnose 显示 cafile 已配置，但 composer install 仍报错或跳过验证，说明问题不在 Composer 层，而在 PHP 层。
- 优先级顺序是：
--cafile命令行参数 >composer.json中的config.cafile>COMPOSER_CAFILE>php.ini的curl.cainfo - 也就是说，即使你设了
COMPOSER_CAFILE，只要php.ini里curl.cainfo指向一个损坏文件，底层 cURL 调用仍会失败并可能降级 - 验证方式：
php -r "print_r(openssl_get_cert_locations());"看的是 PHP 层配置，不是 Composer 层 - 临时绕过时，
COMPOSER_DISABLE_TLS=1是唯一合法方式（-k已废弃），但它会让所有 HTTPS 降级为 HTTP，比跳过证书更危险
Docker 或 CI 环境里证书缺失却误以为已修复
很多 Docker 镜像（尤其是 php:alpine）默认不带 CA 证书包，apk add ca-certificates 后还必须运行 update-ca-certificates，否则证书文件只是空壳。CI 流水线（如 GitHub Actions）里改了 php.ini 却没重启 PHP 进程，或容器启动后没重载配置，也会导致新路径不生效。
- Alpine 正确做法：
RUN apk add --no-cache ca-certificates && update-ca-certificates - Debian/Ubuntu：
RUN apt-get update && apt-get install -y ca-certificates - GitHub Actions 中，不能只改
php.ini就完事，得确保后续步骤在新环境中执行——推荐用docker run -v $(pwd):/app -w /app php:8-cli ...显式指定环境 - CI 里用
COMPOSER_NO_SSL=1最快，但也最危险：它让整个构建过程对所有 HTTPS 源失去防护，包括你自己的私有仓库
真正难排查的点，往往藏在“看似修好了”的假象里：比如 php -r 测试通了，但 Web 环境用的是另一份 php.ini；或者证书文件下载了但权限是 600，CLI 用户可读，而 web server 用户不可读；又或者公司代理重签了 HTTPS 流量，你配了根证书，却没把代理的中间 CA 加进去。这些细节不逐层验证，SSL 验证就永远在“被跳过”和“报错”之间反复横跳。
