Composer怎么通过环境变量传递鉴权Token？避免明文写入配置的安全操作【技巧】-composer-PHP中文网

composer_auth是唯一推荐的ci注入方式，因其为composer 1.10+原生支持的运行时变量，优先级最高、不落地文件、结构严格合法；而composer config --auth会写入易丢失的~/.composer/auth.json且json常不合法，导致私有仓库401。

composer怎么通过环境变量传递鉴权token？避免明文写入配置的安全操作【技巧】

必须用 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 Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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。