私有包源地址必须在项目根目录composer.json的repositories数组中配置，而非全局；需确保type、url合法，改后运行composer update --lock并清缓存验证。
修改 composer.json 中的 repositories 配置
私有包源地址不是写在全局配置里，而是直接定义在项目根目录的 composer.json 文件中。你需要手动编辑这个文件，在 repositories 字段里替换旧的 URL。
常见错误是误改 config 下的 github-protocols 或试图用 composer config 命令覆盖——这些对私有仓库地址无效。
-
repositories必须是数组，每个元素是一个对象，含type（如"vcs"）和url - 如果原地址是 HTTPS 的 GitLab 仓库，新地址也要保持协议一致（比如不能从
https://gitlab.example.com/group/repo.git改成git@gitlab.example.com:group/repo.git，除非你已配好 SSH 密钥且type改为"git"） - 改完后必须运行
composer update --lock（而非仅install），否则composer.lock仍指向旧源
验证是否生效：检查 composer show 和下载行为
改完配置后，composer show vendor/package-name 应该能正确显示包信息；但如果它报 Package not found，说明 Composer 没读到新地址，或新地址不可访问。
更直接的验证方式是加 -vvv 参数触发详细日志：
composer require vendor/package-name:dev-main -vvv
日志里会明确打印出 Composer 正在尝试克隆的 Git 地址——确认它是否为你刚填的新 url。
- 如果日志里仍是旧地址，大概率是没执行
composer update --lock，或composer.json格式有语法错误（比如多了一个逗号） - 如果日志显示新地址但报
Cloning failed，问题就转到了网络、权限或 Git 服务端（如私有 GitLab 是否允许该 token 访问该仓库）
避免缓存干扰：清理 Composer 的 dist / source 缓存
Composer 默认会缓存已下载的包（尤其是 dist 归档），即使你改了源地址，它也可能复用本地缓存，导致你以为“改成功了”，实际拉的还是旧版本。
- 运行
composer clear-cache清掉全部缓存（最保险） - 或者只清特定包：
composer clear-cache && rm -rf ~/.composer/cache/vcs/git-gitlab.example.com-group-repo.git/（路径中的域名和仓库名需按实际替换） - 若使用
composer install而非require，还需删掉vendor/vendor/package-name目录再重装，否则 Composer 可能跳过重新拉取
私有 Git 仓库需要认证时，别只改 URL
单纯把 https://gitlab.example.com/... 改成 https://token:x-oauth-basic@gitlab.example.com/... 是临时方案，不安全也不稳定。推荐两种更可靠的方式：
- 用
composer config设置 HTTP 认证：composer config http-basic.gitlab.example.com username token（token 是 GitLab 的 Personal Access Token，需有read_repository权限） - 改用 SSH +
type: "git"，前提是目标服务器已添加你的公钥，且url改为git@gitlab.example.com:group/repo.git - 注意：HTTP Basic 认证信息存在
auth.json里，不要提交到 Git；SSH 方式则依赖系统级 SSH 配置，CI 环境需额外注入密钥
改地址只是第一步，真正卡住人的往往是认证没跟上，或者缓存没清干净。
