composer本身没有--no-secure或--insecure命令行参数，执行会报错“command not defined”；真正有效的临时绕过方式只有三种：composer_cafile=/dev/null、composer_disable_tls=1或改composer.json为http源，且均须配合验证与清理。
为什么不能用 --no-secure 或 --insecure
Composer 本身没有 --no-secure、--insecure 这类命令行参数。执行 composer install --no-secure 会直接报错：Command "install --no-secure" is not defined。所有网上流传的“加 flag 跳过 SSL”都是无效写法，纯属误导——它根本不会被解析，更不会影响证书校验逻辑。
临时绕过只对当前命令生效的三种方式
真正能起效的临时绕过，必须作用于 Composer 的 HTTP 客户端层（即 cURL），且仅限单次命令，不污染全局配置：
-
COMPOSER_CAFILE=/dev/null composer install（Linux/macOS）或set COMPOSER_CAFILE= && composer install（Windows CMD）：让 Composer 明确使用空 CA 文件，跳过证书链验证 -
COMPOSER_DISABLE_TLS=1 composer install：强制降级为 HTTP 协议（前提是镜像站同时提供 HTTP 接口，如旧版阿里云镜像） -
curl -k https://mirrors.aliyun.com/composer/packages.json验证镜像可用性后，再配合改composer.json中"url"为"http://mirrors.aliyun.com/composer/"，然后运行composer update --lock
注意：COMPOSER_DISABLE_TLS=1 不等于关 SSL，而是让 Composer 放弃 HTTPS，这在 packagist.org 等已强制 HTTPS 的源上会失败；而 COMPOSER_CAFILE=/dev/null 是最底层、最可靠的绕过方式，但仅适用于你确认目标镜像可信、且不涉及敏感依赖的本地调试场景。
改完别忘了清理，否则下次还卡
临时绕过不是一劳永逸的解法，容易被忽略的是：
- 环境变量只对当前 shell 有效，新开终端就失效，但如果你在 CI 脚本里写了
export COMPOSER_CAFILE=...却没 unset，后续命令全受影响 - 改了
composer.json里的repositories为 HTTP 地址后，必须运行composer update --lock，否则composer.lock仍记录着旧的 HTTPS 源地址，安装时照样报错 - 用
composer config -g cafile设置的全局 cafile，优先级低于COMPOSER_CAFILE环境变量，也低于命令行--cafile参数——临时方案若和全局配置混用，行为可能不可预期
真正该修的地方是 php.ini
临时绕过只是让你跑通命令，但问题根源几乎总是 PHP 的 CA 证书路径没配对。运行 php -r "print_r(openssl_get_cert_locations());"，如果 default_cert_file 为空或指向不存在的文件，说明 openssl.cafile 和 curl.cainfo 没设或设错了。这时候改 php.ini 才是一劳永逸的做法——下载 https://www.php.cn/link/5fe4dadcdb001d8566cd20e6d8a20251，存为本地绝对路径，再在 php.ini 里写死两行：
openssl.cafile = "/path/to/cacert.pem" curl.cainfo = "/path/to/cacert.pem"
改完必须关掉当前终端、新开一个，否则 CLI 下的 PHP 进程不会重载配置。这才是多数人反复踩坑却始终没意识到的关键点。
