应优先用全局配置或 Git URL 重写而非手动改 repositories 中的 URL，因硬编码 HTTPS 会导致私有 submodule 访问失败、团队配置不一致、上游迁移维护成本高；推荐 composer config -g default-protocol https 或 git config --global url."git@...".insteadOf "https://..."。
Composer 默认用 git 协议（git@github.com:org/repo.git）拉取代码，但多数内网、CI 或受限环境不支持 SSH，必须切到 HTTPS；直接改 composer.json 里的 URL 是最不可靠的做法，应优先用全局配置或 Git URL 重写。
为什么不能直接在 repositories 里把 git@ 改成 https://？
手动替换 URL 看似简单，但会引发三个实际问题：
- 如果项目用了私有 submodule 或依赖了其他 SSH-only 的仓库，HTTPS 地址根本无法访问（404 或 401）
- 团队成员本地配置不一致：有人配了 PAT，有人没配，
composer install在不同机器上行为不一 - 一旦上游仓库地址变更（比如从 GitHub 迁到 GitLab），所有
repositories都得手动搜改，维护成本高
真正稳定的做法是让 Composer 或 Git 自动做协议转换，而不是硬编码协议。
用 composer config -g default-protocol https 全局强制 HTTPS
这条命令会让 Composer 把所有未显式指定协议的 VCS 地址（包括 GitHub、GitLab、Gitee、自建 Git）都解析为 HTTPS 形式，例如：vendor/package → https://github.com/vendor/package.git。
- 适用于所有平台，不限于 GitHub；比
github-protocols更彻底 - 仅影响“自动推导”的地址，不会覆盖
repositories中已写死的git@或https://URL - 务必确认私有 Git 服务支持 HTTPS + 认证（如 PAT 或 Basic Auth），否则 clone 会失败
- 可选值为
https、ssh、git、http，但http不推荐——无加密、易被劫持、secure-http开启后会被直接拒绝
用 git config --global url."git@github.com:".insteadOf "https://github.com/" 反向切换
当必须走 SSH（比如私有仓库只开放了 SSH 权限），但又不想改 composer.json 里的 HTTPS 地址时，让 Git 层自动重写是最干净的方案。
- 执行后，即使
repositories写的是"https://github.com/org/private"，Git 也会静默转成git@github.com:org/private.git - 对 GitLab 同理：
git config --global url."git@gitlab.com:".insteadOf "https://gitlab.com/" - 该配置不依赖 Composer 版本，也不影响
secure-http判断（因为协议判断在 Composer 层，重写发生在 Git 层） - 注意：若 SSH 配置不全（比如
~/.ssh/config缺 Host 别名或ForwardAgent关闭），composer install仍会卡在 cloning 阶段，且无明确错误提示
验证是否生效及常见失效点
运行 composer config -g -l 查看输出中是否有 default-protocol 或 github-protocols 行。但要注意：
- 如果项目级
composer.json里有"config": {"github-protocols": "ssh"}，它会覆盖全局default-protocol https对 GitHub 仓库的影响 -
secure-http true开启后，任何http://地址都会被拒绝，但不会阻止https://走通——哪怕证书校验失败（那是ssl.cafile的事） - CI 环境中常因基础镜像自带旧版 Composer 或预置了
http://源导致配置被绕过，建议在构建脚本开头加composer self-update && composer config -g -l | grep -E "(default-protocol|secure-http)"
协议切换不是开关游戏，关键在于分清控制层：Composer 控制“用什么协议去请求”，Git 控制“收到请求后怎么执行 clone”；两者配合才能稳住 CI 和多环境部署。
