COMPOSER_AUTH必须为合法JSON字符串，格式如{"github-oauth":{"github.com":"abc123"}}，需双引号包裹且内部引号转义；优先级高于auth.json，但项目存在auth.json时会被跳过，CI/CD推荐使用，本地开发慎用。
Composer 会读取 COMPOSER_AUTH 环境变量，但必须是合法 JSON 格式；直接写明文 token 或错误格式会导致认证失败，且错误提示极不明确。
COMPOSER_AUTH 怎么写才有效
这个环境变量本质是把 auth.json 的内容以 JSON 字符串形式传进去，不是键值对拼接，也不是 Base64 编码。
常见错误：写成 COMPOSER_AUTH="github-oauth.github.com=xxx" 或 COMPOSER_AUTH='{"github-oauth":{"github.com":"xxx"}}'（单引号在 shell 中可能被截断）
- 必须用双引号包裹整个 JSON 字符串，且内部双引号要转义：
export COMPOSER_AUTH="{\"github-oauth\":{\"github.com\":\"abc123\"}}" - 如果 token 含斜杠、加号等特殊字符，不用额外编码，JSON 字符串本身已处理
- 多个源要嵌套完整：
{"github-oauth":{"github.com":"t1"},"http-basic":{"packagist.example.com":{"username":"u","password":"p"}}}
为什么 set-env 命令不生效
composer config --global --auth http-basic.packagist.example.com user pass 是安全的，但 composer config --global --auth 不会读取 COMPOSER_AUTH 变量 —— 它只影响本地或全局 auth.json 文件。
也就是说：COMPOSER_AUTH 是运行时注入，和 config 命令互不干扰，也不能用它“覆盖”已存在的 auth.json 内容。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- CI/CD 中推荐用
COMPOSER_AUTH，避免把auth.json提交或挂载到容器 - 本地开发慎用该变量，容易和
~/.composer/auth.json冲突，导致认证行为不一致 - 执行
composer diagnose不会校验COMPOSER_AUTH是否合法，只有真正请求私有包时才报错
COMPOSER_AUTH 和其他认证方式的优先级
Composer 按固定顺序查找凭证：命令行参数 > COMPOSER_AUTH > auth.json（当前项目）> auth.json（全局）。一旦某处匹配成功，后续就跳过。
这意味着：如果你在项目根目录放了 auth.json，即使设置了 COMPOSER_AUTH，它也不会被使用 —— 除非你删掉或重命名那个文件。
-
--no-auth参数可强制跳过所有认证，用于调试是否真由COMPOSER_AUTH驱动 - 私有 Packagist 实例若启用了 OAuth2，
COMPOSER_AUTH中的http-basic段无效，必须走github-oauth或自定义 OAuth 流程 - GitLab 私有仓库需用
gitlab-token字段，不是http-basic，格式为{"gitlab-token":{"gitlab.com":"xxx"}}
最麻烦的点在于：环境变量解析失败时 Composer 不报语法错误，而是静默回退到下一级认证方式，最后卡在 401 或 “Could not fetch” 上。建议先用 echo $COMPOSER_AUTH | jq . 验证 JSON 合法性，再测试安装一个私有包。
