secure-http 默认开启但必须显式确认生效，否则镜像或私有仓库可能被降级为HTTP导致签名验证失效；需确保全局配置为true、所有仓库URL以https://开头且结尾带/、系统TLS栈信任证书，并通过composer diagnose验证secure-http: OK和HTTPS connectivity: OK。
secure-http 默认已开启，但必须显式确认生效，否则镜像源或私有仓库可能被降级到 HTTP，签名验证失效。
为什么 secure-http 开关不能只靠“默认值”
Composer 2.2+ 确实默认设为 true，但这个值极易被覆盖：项目级 composer.json 中的 "secure-http": false 会覆盖全局配置；某些旧脚本或 CI 模板会静默写入 false；更隐蔽的是，repo.packagist 配置若用了 HTTP URL（如 http://mirrors.aliyun.com/composer/），Composer 会直接报错或 fallback 到无校验模式，而不会提示你 secure-http 被绕过。
- 运行
composer config -g secure-http必须输出true，不是空或false - 检查所有项目根目录下的
composer.json，搜索"secure-http"字段，删掉或改为true - 若用
composer create-project初始化，模板里可能自带错误配置，需初始化后立刻验证
secure-http: true 生效的三个硬性前提
仅设 secure-http 不够，它只拦 HTTP 源，不保证 HTTPS 请求真能走通或校验有效。必须同时满足：
- 所有
repositories的url必须以https://开头，且末尾带/（例如https://mirrors.tencent.com/composer/，少斜杠会 404） - 不能存在
type: "package"或type: "path"类型仓库指向本地 HTTP 服务——这类仓库不受secure-http约束，但可能被误配成http://localhost:8000 - 系统 TLS 栈必须信任目标证书：若连私有 Artifactory，
curl -Iv https://your.repo.com/packages.json必须成功握手并返回200，否则secure-http会卡住或静默失败
常见失效现象和快速定位命令
典型症状不是报错，而是 composer install 看似成功，但 composer audit 漏检、或某天突然拉到被篡改的 packages.json。
- 执行
composer diagnose，输出中必须同时出现secure-http: OK和HTTPS connectivity to packagist.org: OK—— 缺一不可 - 若提示
curl error 60或SSL certificate problem，说明证书链未被信任，此时secure-http已起作用（它拒绝了不安全连接），但你需要配ssl.cafile而不是关掉它 - 检查镜像源是否被实际使用：
composer config -g repo.packagist输出应为完整 JSON 对象，含"type": "composer"和"url": "https://..."；若输出为空或格式错误，说明镜像未生效，secure-http就在保护一个根本没走的路径
最易被忽略的是：secure-http 只管「协议」，不管「证书有效性」。它放行了 HTTPS 请求，但后续的证书校验、签名验证（security.signature）、镜像源是否同步 signature 字段，是三道独立防线——缺哪一层，都可能让恶意包混入 vendor 目录。
