Composer 仍出现 HTTP 下载或警告，是因为 secure-http 被显式设为 false；需通过 composer config [-g] secure-http 检查并设为 true，且私有仓库 URL 也必须为 HTTPS。
Composer 默认已强制 HTTPS，无需额外配置——但必须确认你的全局或项目配置没关掉它。
为什么还会遇到 HTTP 下载或警告？
常见现象是执行 composer install 或 composer update 时出现 Warning: Accessing packagist.org over http which is an insecure protocol.，或者包下载卡在某个 HTTP 地址上。这不是 Composer 版本太旧，而是配置被显式关闭了安全限制。
Composer 自 2.0 起默认启用 secure-http，但这个开关可被手动设为 false，尤其在老旧项目或某些 CI 脚本里会看到：
{"config": {"secure-http": false}}
一旦这么写，Composer 就允许回退到 HTTP（比如某些私有源没配 HTTPS），也就失去了传输层保护。
如何检查并启用 secure-http
- 查全局配置：
composer config -g secure-http—— 输出true表示已启用；若输出false或空，说明被禁用 - 查项目配置：
composer config secure-http（不加-g）——优先级高于全局，以项目根目录下的composer.json为准 - 启用它：
composer config -g secure-http true（全局生效）或composer config secure-http true（仅当前项目） - 如果项目
composer.json里已有"secure-http": false，直接删掉这一行或改成true即可
secure-http 关闭后的真实风险
它不只是“警告消失”那么简单：
- HTTP 源可能被中间人篡改响应，导致你下载的 zip 包内容被替换（例如植入后门）
- Composer 不校验 HTTP 响应的 TLS 证书，连基本域名匹配都不做，攻击者只需劫持 DNS 或路由就能伪造整个包仓库
- 某些企业防火墙或代理会拦截或重写 HTTP 流量，造成
Invalid zip file或Hash mismatch错误，而这些错误在 HTTPS 下几乎不会发生 - 即使你用的是国内镜像（如阿里云
https://mirrors.aliyun.com/composer/），只要secure-http关了，Composer 仍可能 fallback 到原始 HTTP 地址
别漏掉私有仓库的 HTTPS 配置
如果你在 composer.json 里加了自定义 repositories，比如 GitLab 或私有 Packagist，它们也必须用 HTTPS URL，否则 secure-http 会直接拒绝加载：
{"type": "composer", "url": "http://repo.example.com"}
上面这行会导致 Could not parse version constraint ... Invalid repository config 类错误。必须改成：
{"type": "composer", "url": "https://repo.example.com"}
注意：自签名证书或内部 CA 签发的证书，默认会被 Composer 拒绝（报 cURL error 60）。此时不能关 secure-http，而应配置 cafile 或把证书加入系统信任链。
