COMPOSER_AUTH是唯一推荐的CI注入方式，因其为Composer 1.10+原生支持的运行时变量，优先级最高、不落地文件、结构严格合法；而composer config --auth会写入易丢失的~/.composer/auth.json且JSON常不合法，导致私有仓库401。
必须用 COMPOSER_AUTH 环境变量，且值是合法 JSON 字符串——不是 Base64 编码，不是键值对拼接，也不是单引号包裹的字符串。
为什么 COMPOSER_AUTH 是唯一推荐的 CI 注入方式
CI runner 每次都是干净容器，composer config --auth 会写入 ~/.composer/auth.json，但该路径在容器重启后即丢失；更关键的是，它生成的 JSON 结构常不严格合法（比如字段顺序错、多逗号、权限位不对），导致私有仓库（尤其是 GitLab Package Registry 或自建 Satis）直接返回 401。
COMPOSER_AUTH 是 Composer 1.10+ 原生支持的运行时变量，优先级高于所有本地 auth.json，且不落地文件——只在内存中解析一次，完全规避文件残留和权限问题。
- 它不依赖任何交互或全局配置，适合无 tty 的 CI 场景
- 值必须是双引号包裹的合法 JSON，例如：
{"http-basic":{"repo.example.com":{"username":"token","password":"abc123"}} - 若项目根目录存在
auth.json，Composer 会跳过COMPOSER_AUTH—— 调试时先确认该文件是否被git rm --cached auth.json移出索引
COMPOSER_AUTH 的 JSON 格式怎么写才不报错
常见错误不是 Token 写错，而是 JSON 本身非法：多空格、换行、单引号、未转义引号、斜杠漏转义。Shell 中直接 export 时，内部双引号必须转义。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- GitHub OAuth 场景（需 Composer ≥2.2）：
{"github-oauth":{"github.com":"${{ secrets.GITHUB_TOKEN }}"}}，注意auth.json中要写成"github.com": "${GITHUB_TOKEN}"才能触发变量替换 - GitLab 私有包必须用
gitlab-token字段，不是http-basic：{"gitlab-token":{"gitlab.com":"glpat-xxx"}} - 多个源混用时，嵌套结构不能扁平化：
{"http-basic":{"a.com":{"u":"v"}}, "github-oauth":{"github.com":"t"}}—— 少一个}或多一个逗号都会静默失败 - 不要用
echo '{"k":"v"}' | base64编码再设变量，那是过时做法；当前 Composer 版本（≥2.2）直接读原始 JSON，Base64 反而会导致解析失败
CI 中怎么安全注入又不泄露日志
GitHub Actions 和 GitLab CI 都支持 masked secrets，但变量注入姿势不对，Token 仍可能出现在 debug 日志或 env 输出里。
- GitHub Actions：在 job 的
env下直接写COMPOSER_AUTH: ${{ secrets.COMPOSER_AUTH }}，Secret 内容就是上面那段纯 JSON（双引号已转义好） - GitLab CI：新建
masked类型变量COMPOSER_AUTH_JSON，然后在before_script中校验并导出：echo "$COMPOSER_AUTH_JSON" | php -r "json_decode(file_get_contents('php://stdin')) or die('invalid json');"，再export COMPOSER_AUTH="$COMPOSER_AUTH_JSON" - 绝对不要在
script里用echo打印变量内容，也别在composer install -v模式下运行——Verbosity 会把 URL 中的认证部分（如果误配了）原样吐出来
本地开发要不要用 COMPOSER_AUTH？
不要。本地环境已有 ~/.composer/auth.json，用 composer config --global --auth 更稳定；启用 COMPOSER_AUTH 后，一旦忘记 unset，就会和本地文件行为不一致，比如某次 composer update 成功，换台机器却 401，排查成本极高。
真正容易被忽略的是：很多团队在 docker-compose.yml 里用 environment: 直接写死 JSON 字符串，但 YAML 解析器会吃掉内部引号或换行——必须用 literal block（|）或提前 base64（仅限旧版兼容场景），否则容器内看到的 $COMPOSER_AUTH 根本不是有效 JSON。
