secure-http 默认为 true 且强制 HTTPS，关闭需用 --global 参数并确保仓库 URL 全为 https://；配置生效需满足 URL 协议、签名验证、CA 信任链等多层校验。
secure-http 默认为 true，意味着 Composer 会拒绝所有 HTTP 协议的仓库源；它不是“可选开关”，而是强制 HTTPS 的安全基线——关掉它等于主动放弃防中间人攻击的第一道防线。
为什么 composer config secure-http false 不生效
这条命令只写入当前项目的 composer.json，而 secure-http 是全局配置项，Composer 优先读取 ~/.composer/config.json（或 $COMPOSER_HOME/config.json）。项目级配置不覆盖它。
- 正确做法是加
--global：运行composer config --global secure-http false - Composer 2.5+ 开始默认忽略该配置，必须配合
--no-secure-http参数使用，例如：composer update --no-secure-http - 即使关了
secure-http，若composer.json里仍保留"url": "http://xxx"，依然报错 —— 必须同步改成https://或删掉该仓库 - 执行后用
composer config --global --list | grep secure-http确认是否真写入，JSON 格式错误（如多逗号、单引号）会导致整段配置失效
secure-http 关闭后还提示 “insecure protocol” 怎么办
这不是配置没生效，而是 Composer 在解析 repositories 时对 URL 协议做了硬校验：只要发现 http:// 开头的地址，就直接拒绝加载，不走任何配置判断逻辑。
- 检查
composer.json中所有repositories的url字段，包括 Packagist 官方源是否被意外覆盖（比如某脚本写了"packagist.org": {"url": "http://..."}） - 国内镜像如阿里云、腾讯云，必须用
https://mirrors.aliyun.com/composer/，旧的http://地址已不可用 - 某些私有仓库配置了
http://localhost:8000测试，但本地服务未启动，也会卡在连接阶段，现象类似安全报错 - 用
curl -I http://your-repo.com/packages.json验证是否真能响应；如果返回 301 跳转到 HTTPS，则说明服务端强制升级，本地关配置也没用
如何验证 secure-http 是否真正起作用
不能只看有没有报错，要确认实际请求路径和响应头是否符合预期。最可靠的方式是组合诊断命令 + 手动探测。
- 运行
composer diagnose，输出中必须同时出现secure-http: OK和signature verification: OK—— 前者表示 HTTPS 强制启用，后者表示包完整性校验链完整 - 临时删掉所有自定义
repositories，仅保留默认源，再执行composer clear-cache && composer install -vvv，观察日志里是否全部走https://packagist.org/... - 若用代理或 CI 环境，注意环境变量
HTTP_PROXY/HTTPS_PROXY会覆盖 Composer 配置；先运行unset HTTP_PROXY HTTPS_PROXY再测试 - 某些企业网络会劫持 DNS 或注入重定向，导致看似 HTTPS 实际被中间设备降级 —— 最终得靠
openssl s_client -connect packagist.org:443 -servername packagist.org看证书链是否可信
关键点在于：secure-http 不是独立开关，它和仓库 URL 协议、签名验证、系统 CA 信任链、网络中间设备共同构成一层嵌套校验。任一环节松动，安全模型就失效——而问题往往不出在配置本身，出在你没看到的那层跳转或缓存里。
