disable-tls不是合法配置项，Composer 2.0+已彻底移除，执行composer config --global disable-tls true仅写入无效字段，运行时被完全忽略；真正应修复CA证书或临时用COMPOSER_DISABLE_TLS=1单次绕过。
disable-tls 不是配置项，它根本不会生效
Composer 2.0+ 版本中，disable-tls 已被彻底移除，既不是合法的 config 配置字段，也不在源码中存在对应逻辑。你执行 composer config --global disable-tls true 看似成功，实际只是把无效键值写进了 auth.json 或 composer.json，运行时完全被忽略。TLS 校验照常进行，或者更糟：请求因证书异常直接失败，而你误以为“已关闭 TLS”导致排查方向错误。
所谓“禁用 TLS”实为降级到 HTTP 明文传输
即使在极旧版本（如 Composer 1.x）中设了 disable-tls，它的行为也不是“跳过证书验证”，而是强制退化到 HTTP 协议——所有包元数据、下载链接、甚至 OAuth token 都以明文暴露在网络中。这带来两类高危风险：
- 中间人可篡改
composer.lock中的哈希值，注入恶意包 - 私有仓库的
http-basic凭据（用户名/密码）被截获后可直接复用 - 企业内网若存在代理或镜像层，HTTP 流量可能被缓存或日志留存
secure-http=false 才是真正允许 HTTP 的开关
secure-http 和 disable-tls 完全不同：secure-http 控制是否允许使用 HTTP 协议访问仓库；而 disable-tls 是个早已失效的伪配置。如果你需要对接一个不支持 HTTPS 的内网私库，正确做法是：
- 只对目标仓库设置
"secure-http": false，而非全局关闭 - 在
repositories中显式声明该仓库，并配"type": "composer"和"url": "http://private-repo.local" - 避免同时设
secure-http: false和disable-tls: true——后者无效，前者已足够危险
真正该修的是 CA 证书路径，不是关安全开关
95% 的 “SSL certificate problem” 报错，根源是 PHP 的 OpenSSL 没法加载可信 CA 证书，而不是证书本身有问题。验证方式很简单：
运行 php -r "print_r(openssl_get_cert_locations());"，检查 default_cert_file 路径是否存在且非空。常见修复路径：
- Linux（Debian/Ubuntu）：
sudo apt install --reinstall ca-certificates，然后重启终端或 PHP-FPM - macOS（Homebrew）：
brew reinstall ca-certificates，再确认openssl.cafile指向正确路径 - 仅对 Composer 生效（不改 php.ini）：
composer config -g repo.packagist.org.ssl.certificate-authority /etc/ssl/certs/ca-certificates.crt
临时绕过验证唯一可控的方式是单次命令加环境变量：COMPOSER_DISABLE_TLS=1 composer require vendor/pkg。注意：它仍走 HTTPS，只是跳过证书链校验，不等于明文传输——但依然不可用于生产。
