Composer如何理解COMPOSER_AUTH变量_Composer COMPOSER_AUTH变量步骤-composer-PHP中文网

composer_auth必须是合法json字符串且优先级低于项目级auth.json；正确写法为export composer_auth='{"github-oauth":{"github.com":"ghp_abc123"}}'，base64编码会导致解析失败。

composer如何理解composer_auth变量_composer composer_auth变量步骤

COMPOSER_AUTH 不是“传进去就能用”的环境变量，它必须是合法 JSON 字符串，且一旦项目目录存在 auth.json，Composer 就直接跳过它——这是绝大多数人踩坑的根源。

早期文档有误导，声称要 Base64 编码；但自 Composer 2.2+ 起（当前稳定版默认已远超此版本），COMPOSER_AUTH 直接接受未编码的 JSON 字符串。Base64 反而会导致解析失败，报错极不明确（比如静默跳过认证、或 Could not fetch 401）。

✅ 正确写法：export COMPOSER_AUTH='{"github-oauth":{"github.com":"ghp_abc123"}}'
❌ 错误写法：export COMPOSER_AUTH="eyJnaXR..."（Base64 后的乱码）
JSON 内部所有双引号必须保留，不能用单引号替代；键名如 github-oauth、http-basic 必须拼写准确，大小写敏感
GitLab 私有包要用 gitlab-token 字段，不是 http-basic 或 github-oauth；域名必须是实际 API 域名（如 gitlab.example.com，不是 gitlab.com）

Composer 查找认证凭据有严格顺序：命令行参数 → COMPOSER_AUTH 环境变量 → 项目根目录的 auth.json → 全局 auth.json。只要某一级匹配成功，后续全部跳过。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

如果你在项目里放了 auth.json（哪怕内容为空或格式错误），COMPOSER_AUTH 就完全不会被读取
CI/CD 中推荐删掉或重命名项目级 auth.json（例如改名成 auth.json.disabled），再通过 COMPOSER_AUTH 注入
本地开发慎用该变量——容易和 ~/.composer/auth.json 行为不一致，调试时建议加 --no-auth 强制关闭所有认证，确认是否真由环境变量驱动
验证是否命中：运行 composer install -vvv，观察日志中是否有 Reading authentication from environment variable COMPOSER_AUTH（部分版本会打印）

GitHub Actions、GitLab CI 等平台支持直接在 env 块注入，但要注意 shell 解析和 secret 注入时机。

GitHub Actions 示例（推荐）：
```
env:
  COMPOSER_AUTH: '{"github-oauth": {"github.com": "${{ secrets.GITHUB_TOKEN }}"}}'
```
注意外层单引号包裹，内部双引号保留；${{ secrets.GITHUB_TOKEN }} 会被自动展开，无需额外转义
避免在脚本里拼接字符串：COMPOSER_AUTH="{\"github-oauth\":...}" 容易漏转义，出错难排查
不要用 composer config http-basic 动态写入 auth.json——这会在工作区留下明文凭据，CI 日志可能泄露，且缓存污染风险高
调试时可临时加一行：php -r "echo json_last_error_msg(); var_dump(json_decode(\$_SERVER['COMPOSER_AUTH'], true));"，快速确认 JSON 是否合法

真正麻烦的从来不是写对那一行 JSON，而是忘记项目目录下那个静静躺着的 auth.json 文件——它像一个沉默的开关，一碰就让整个环境变量失效。每次怀疑 COMPOSER_AUTH 不工作，先 ls -a | grep auth。