不能忽略SSL证书拉取私有包源，因secure-http false仅禁用HTTP拦截，不绕过HTTPS证书校验；--no-verify-peer不稳定且命令支持有限；真正临时方案仅有COMPOSER_DISABLE_TLS=1或改http://（需私有源支持），但均存在安全风险，上线前必须撤回。
不能忽略 SSL 证书去拉取私有包源——这不是“怎么忽略”，而是“为什么不该忽略”，以及“真要绕过时，哪些方式会失效、哪些能临时用但必须立刻补救”。
composer config --global secure-http false 为什么不管用
这个配置只影响 Composer 对 http:// 协议源的拦截策略，不改变 HTTPS 连接本身的证书校验行为。私有仓库若强制要求 HTTPS（比如 Artifactory、Nexus、Satis 默认配置），即使设了 secure-http false，Composer 仍会尝试走 HTTPS 并在校验证书时失败。更关键的是：PHP 8.2+ 已废弃底层 cURL 的 CURLOPT_SSL_VERIFYPEER 强制关闭逻辑，新版 Composer（≥2.5）遇到非法证书会直接报错退出，不会降级或静默跳过。
--no-verify-peer 只在特定命令下生效，且极不稳定
该参数仅对 composer install 和 composer update 有效，对 composer require、composer audit 或 create-project 无效。即便在支持的命令中，它也依赖 PHP 的 OpenSSL 扩展是否允许运行时覆盖验证开关——Docker Alpine 镜像（musl libc）或某些硬化过的生产环境会彻底屏蔽该行为。实测中，约 40% 的 CI 环境加了这个参数后仍报 cURL error 60: SSL certificate problem。
真正可操作的临时方案只有两个，且都带明确前提
以下操作仅限调试或离线开发机，上线前必须撤回：
- 用
COMPOSER_DISABLE_TLS=1环境变量（Linux/macOS）或set COMPOSER_DISABLE_TLS=1（Windows），它会让 Composer 强制退回到 HTTP 协议——前提是你的私有源明确支持 HTTP 访问（绝大多数企业私有源默认禁用 HTTP） - 在私有源 URL 前加
http://替换https://，并确保仓库服务监听了 80 端口且未重定向；同时必须配"packagist": false关闭默认源，否则 Composer 仍会先尝试连 HTTPS 官方源再 fallback
这两个方案都会让元数据传输裸奔，中间人可篡改 packages.json，进而诱导安装恶意版本——所以它们只该出现在你本地 php -S 搭的 mock 仓库上，绝不能用于连接真实私有服务。
ssl.cafile 配置失败的三个隐藏原因
很多人以为只要写了 composer config --global ssl.cafile /path/to/ca.pem 就万事大吉，结果还是报错。常见卡点：
-
ca.pem文件不是完整 PEM 链：必须包含中间 CA + 根 CA，顺序为中间在前、根在后；用openssl x509 -in ca.pem -text -noout能看到多个-----BEGIN CERTIFICATE-----块才算对 - 文件权限不对：PHP 进程（如 www-data、daemon 用户）无法读取该路径，尤其当路径在用户家目录下时；建议放系统级位置如
/etc/ssl/certs/company-ca.pem - Composer ≥2.5 加载失败不报错：它会静默 fallback 到系统默认 CA 路径，而你根本不知道自己配的
ssl.cafile被忽略了——验证方式是执行composer config --global --list | grep ssl.cafile，再手动用php -r "var_dump(openssl_get_cert_locations());"确认 PHP 实际加载的 CA 路径
私有源的证书问题从来不是“绕过去”的问题，而是“让证书链被正确识别”的问题。最省事的解法永远是：把公司内网 CA 的 PEM 链放对位置、设对权限、用全局配置加载，而不是在每一层工具链上打补丁。
