Composer读取gitlab-token的唯一有效位置是auth.json，必须置于用户主目录
很多开发者配置GitLab私有仓库时，会在auth.json上栽跟头。这里必须明确一点：Composer读取gitlab-token的唯一有效位置，就是放在用户主目录下的那个auth.json文件（路径是~/.composer/auth.json或%APPDATA%\Composer\auth.json）。路径或字段名但凡写错一个字符，配置就完全不起作用。
auth.json 文件路径和结构必须严格正确
Composer只在两个地方寻找auth.json：全局的用户主目录，或者项目根目录（但后者需要配合COMPOSER_AUTH环境变量使用）。默认情况下，放在项目里的./auth.json是无效的。
文件本身的结构也有硬性要求：
- 它必须是合法的JSON格式，顶层是一个对象，并且不能有尾随逗号这类语法错误。
- 字段名必须精确地写成
gitlab-token。写成token、access_token或者http-basic都不行。 - 域名的key必须与仓库URL的host部分一字不差地匹配，不能包含协议、路径，端口也要看情况。举个例子，
gitlab.example.com:8080和gitlab.example.com在Composer看来是两个完全不同的key。 - 常见的错误写法包括
{"https://gitlab.com": {...}}或{"gitlab.com/api/v4": {...}}——这些错误的key会被Composer直接忽略。
gitlab-token 值必须是 Personal Access Token，且权限完整
令牌本身也有讲究。Deploy Token、CI_JOB_TOKEN、OAuth App Token这些统统不支持API调用，如果用了，Composer在获取包元数据的阶段就会报错失败。
正确的做法是：
- 在GitLab的用户设置（Settings → Access Tokens）页面创建Personal Access Token。
- 创建时，务必勾选
read_api权限（否则会报403 Forbidden错误）和read_repository权限（否则git clone会失败）。 - 如果是企业内部部署的GitLab实例，对应的用户还需要对目标项目拥有Reporter或更高级别的访问权限。
- 令牌生成后，请立即复制并妥善保存，因为页面一旦刷新，就再也看不到明文的令牌了。
composer.json 中必须声明 vcs 类型仓库
只配置auth.json是不够的。Composer并不会自动扫描所有可能的域名，它需要你明确告诉它：该向哪个地址发起GitLab API请求。
这就需要在composer.json里做好声明：
- 在
repositories数组中，必须包含一个"type": "vcs"的条目。 url字段必须是完整的HTTPS格式Git仓库地址，并以.git结尾，例如："https://gitlab.example.com/group/lib.git"。- 注意，不能用SSH地址（如
git@gitlab...），否则Composer会跳过token认证流程。 - 同时，
require部分也必须包含对应的包名，否则Composer根本不会尝试去访问这个源。
调试时看 -v 输出里的 Authorization 请求头
配置完成后如何验证？运行composer update -v命令，仔细观察输出日志。关键要看其中是否出现了类似Authorization: Bearer glpat-这样的请求头。如果没有，那就说明token没有成功匹配上域名，或者auth.json文件根本没被加载。
可以按以下步骤排查：
- 执行
composer config --global --list | grep gitlab，确认没有其他配置（比如http-basic）覆盖了你的设置。 - 直接运行
git ls-remote https://gitlab.example.com/group/lib.git来测试Git层是否通畅。如果这个命令也弹出密码框，说明系统级的凭据助手没配置好，Composer必然也会失败。 - Composer的缓存可能会保留旧的401错误响应，记得在执行前运行
composer clear-cache清除缓存再试。
最后，有几个最容易被忽略的细节值得再次强调：域名匹配必须一字不差（包括端口）；gitlab-token字段不能错误地嵌套在http-basic结构下面；以及在composer.json中声明vcs仓库是强制前提。这三者缺了任何一个，你配置的token就等于白写了。
