Git仓库安全取决于认证方式、凭证存储和传输协议三者组合；HTTPS+Token与SSH是主流方案，任一环节配置错误会导致明文传输或静默失败。
直接用 HTTPS 或 SSH 连 Git 仓库本身不安全，真正决定安全性的，是认证方式、凭证存储位置和网络传输协议三者的组合。HTTPS + Token 和 SSH 是目前最主流且可落地的方案，但配置错一个环节就会降级为明文传输或静默失败。
auth.json 放哪、权限多少才被 Composer 读取
Composer 只认全局 auth.json：Linux/macOS 是 ~/.composer/auth.json，Windows 是 %APPDATA%\Composer\auth.json。项目根目录下的 auth.json 完全无效。
- 文件权限必须是
600（Linux/macOS）：运行chmod 600 ~/.composer/auth.json，否则 Composer 会跳过整个文件，且不报错 - 顶层 key 必须是
http-basic、bearer或gitlab-token等合法类型，不能写成github-oauth去配 GitLab - 域名 key 必须与仓库 URL 的 host 部分完全一致，比如
gitlab.example.com:8080和gitlab.example.com在 Composer 看来是两个不同源
HTTPS 方式填 URL 时为什么总被跳过
Composer 对 VCS 仓库的 url 字段校验极严，填错不会提示，而是直接忽略该仓库——你执行 composer update 时根本看不到它参与解析。
-
url必须以.git结尾，例如https://gitlab.example.com/myorg/sdk.git，少这个后缀就失效 - 不能填网页地址，比如
https://gitlab.example.com/myorg/sdk/-/tree/main，这是浏览器用的，不是 Git 协议地址 - 禁止使用旧式 token 写法：
https://token:x-oauth-basic@gitlab.example.com/在 Composer 1.10+ 已被移除 - 验证是否真能通：新开终端执行
git ls-remote -h https://gitlab.example.com/myorg/sdk.git，能列出分支才算通过
SSH 方式为什么本地能连上，Composer 却失败
本地 ssh -T git@gitlab.example.com 成功，不代表 Composer 就能用 SSH 拉代码——它依赖的是系统级 SSH agent 的环境上下文，而 CI/CD 或 Docker 构建中这个上下文常常缺失。
- GitHub Actions 默认不加载 SSH agent，需显式加
ssh-agent步骤并ssh-add私钥 - Docker 构建中未挂载
~/.ssh目录或未启动 agent，git clone git@会卡住或超时 - 私钥带密码（passphrase）时，Composer 不支持交互式输入，必须用
ssh-keygen -N "" -f ~/.ssh/id_rsa生成无密钥版本 - 公钥应添加到 Git 平台的 Deploy Keys（而非用户 SSH Keys），避免权限过大
GitLab 专用配置容易漏的关键点
GitLab 有自己的一套认证逻辑，混用 GitHub 配置方式大概率失败。
- 如果用
gitlab-token，auth.json中要写成：{"gitlab-token": {"gitlab.example.com": "glpat-xxx"}} - 如果用
http-basic，用户名必须是oauth2（GitLab 固定值），密码填glpat-xxx - 仓库
type推荐统一用vcs，不要写gitlab——后者是旧版兼容模式，已逐步弃用 - 若内网 GitLab 用 HTTP（非 HTTPS），必须在
composer.json的config中设"secure-http": false，否则 Composer 会拒绝连接
最常被忽略的是：即使所有配置都对，Composer 也会缓存失败的元数据。遇到问题先清缓存：composer clear-cache，再删掉 vendor/ 和 composer.lock 重试——否则你改了十次 auth.json，它还在用旧缓存里的 401 响应。
