Bearer Token认证必须通过auth.json或COMPOSER_AUTH环境变量配置，不可写入composer.json或URL内联；auth.json中需为顶层{"bearer": {"domain": "token"}}结构，域名须与仓库URL主机名逐字符一致，且JSON格式严格合法。
Bearer Token 认证必须通过 auth.json 或 COMPOSER_AUTH 环境变量配置，不能写进 composer.json，也不能用 URL 内联（如 https://token:abc123@...）——否则 Composer 直接忽略整个仓库条目。
Bearer Token 怎么写进 auth.json 才有效
Composer 只识别顶层键为 bearer 的 JSON 结构，且域名必须与仓库 URL 主机名逐字符一致。常见失效点是多了一层包装、用了注释、或拼错字段名。
-
auth.json必须是标准 JSON：无单引号、无尾逗号、无注释 - 内容只能是
{"bearer": {"packages.example.com": "ghp_abc123"}}这种扁平结构，不能写成{"config": {"bearer": {...}}} - 如果仓库 URL 是
https://api.myrepo.internal/v2，域名就得填api.myrepo.internal，填myrepo.internal或带路径都失败 - Token 字符串本身不用 Base64 编码，也不加
Bearer前缀——Composer 会自动加上
为什么 composer config bearer.xxx 有时不生效
命令行方式看似方便，但容易踩两个隐性坑：一是没加 --global 导致写入项目级 auth.json（而你实际在全局上下文运行），二是当前目录已有项目级 auth.json 且它优先级更高，覆盖了全局设置。
- 运行
composer config --global --list | grep bearer确认是否真写进去了 - 若输出为空，检查是否误用了
composer config bearer.xxx token（缺--global）导致写入了当前项目目录下的auth.json - 项目级
auth.json优先级高于全局，删掉项目根目录的auth.json再试一次
CI/CD 中用 COMPOSER_AUTH 环境变量的硬性要求
环境变量值必须是合法 JSON 字符串，且不能被 shell 解析破坏。很多 CI 脚本直接拼接字符串导致 JSON 格式非法，结果静默失效。
- 正确写法：
COMPOSER_AUTH='{"bearer":{"packages.example.com":"ghp_abc123"}}' - 错误写法：
COMPOSER_AUTH={"bearer":{"packages.example.com":"$TOKEN"}}（未加单引号，shell 会尝试展开变量或报错） - GitHub Actions 中推荐用
env:+secrets.注入，避免日志回显；GitLab CI 则需勾选 “Mask variable” 并确认值不含换行 - 执行
composer diagnose后若看到bearer: OK行，说明已加载成功
Bearer 认证本身不校验 Token 权限范围，出问题时往往不是“连不上”，而是“连上了但拉不到包”——这时候得回头核对 Token 是否有 read:packages 权限，以及私有源是否真支持 Bearer 方式（有些只认 http-basic 或 custom-headers）。
