secure-http为true时强制所有仓库使用HTTPS，任何http:// URL均被直接拒绝报错；因Packagist官方源在Composer 2.0+中硬编码处理，修改repo.packagist.org无效，必须设置composer config -g secure-http true生效。
secure-http 控制 Composer 是否允许 HTTP 协议访问仓库，设为 true 时任何 http:// URL 都会被直接拒绝——不是警告，是报错退出。
为什么改了 repo.packagist.org 还没用
因为 Packagist 官方源在 Composer 2.0+ 中被硬编码处理，repo.packagist.org 这个配置项根本不会被读取。你执行 composer config -g repo.packagist.org https://packagist.org 是白忙活。
真正起作用的是全局开关 secure-http：它不改 URL，而是在每次重定向或解析仓库地址时做协议校验。只要响应头里出现 http://，就立刻中止。
- 执行
composer config -g secure-http true才是正解 - 验证是否生效：
composer config -g secure-http应输出true - 如果某次
update报出The 'http://' URL 'http://packagist.org/p/xxx.json' is not allowed，说明它已生效
composer.json 里有 http:// 就会立即失败
Composer 不是等下载时才检查协议，而是在解析 composer.json 阶段就扫描所有 repositories 数组里的 url 字段。只要其中一条是 http:// 开头，整个命令就会退出，连锁文件都不读。
- 逐行检查
repositories，把"url": "http://packages.internal"改成"url": "https://packages.internal" - 改完必须删掉
vendor/和composer.lock，否则旧锁文件可能缓存错误源信息 - 若内网服务确实不支持 HTTPS，只能在该仓库对象里加
"allow_ssl_downgrade": true，不能提级到根节点
default-protocol https 和 secure-http 的区别
default-protocol 解决的是 Git 地址推导问题，比如你写 "vendor/package"，它自动补成 https://github.com/vendor/package.git；而 secure-http 管的是所有仓库元数据拉取（包括 Packagist、私有 Composer 源）的协议强制校验。
- 设
default-protocol不影响repositories里已写死的git@或http://地址 - 设
secure-http true后，哪怕default-protocol是git，只要仓库 URL 是http://，照样报错 - 两者常一起用：
composer config -g default-protocol https+composer config -g secure-http true
curl error 35 或 60 不是 secure-http 的锅
报 cURL error 35 (SSL handshake failed) 或 cURL error 60 (SSL certificate problem)，说明 HTTPS 请求发出去了，只是握手失败或证书不被信任——这和 secure-http 是否开启无关，而是系统 CA 证书、PHP 的 curl.cainfo 或 Composer 的 cafile 配置出了问题。
- 先手动测试：
curl -I https://packagist.org/packages.json，失败则优先修环境，别急着关secure-http - Ubuntu/Debian 上缺证书包：
sudo apt install ca-certificates - Composer 2.5+ 对
ssl.cafile路径更敏感，必须是 PEM 格式、无 BOM、无注释、PHP 进程可读
最容易被忽略的是：这个设置只拦「出站请求」，不保「入站来源」。如果你的私有仓库用了自签名证书，或者镜像服务没配好中间 CA，secure-http true 只会让错误提前暴露，而不是绕过它。
