简化授权管理：使用Composer管理商业付费组件的秘钥分发-composer-PHP中文网

商业组件授权密钥不可手动复制粘贴分发，必须通过auth.json等机制实现凭据与代码分离；严禁写入composer.json或提交至git，否则导致历史泄露、ci日志暴露及协作断裂；应利用环境隔离、加密secrets动态生成auth.json，并严格校验域名与权限范围。

简化授权管理：使用composer管理商业付费组件的秘钥分发

商业组件的授权秘钥不能靠手动复制粘贴分发，否则必然在团队协作、CI/CD 和多环境部署中出问题。 Composer 本身不提供秘钥托管能力，但可以通过组合 auth.json、私有仓库配置和环境隔离机制，把秘钥作为“认证凭据”而非“代码资产”来管理——这才是可落地的简化路径。

为什么不能把秘钥写进 `composer.json` 或提交到 Git

这是最常踩的坑：有人把 "token": "xxx" 直接塞进 repositories 配置里，甚至提交到仓库。后果很直接：

Git 历史永久泄露秘钥，撤回成本极高
CI 环境（如 GitHub Actions）若未严格屏蔽敏感变量，composer install 会直接暴露 token 到日志
开发同事 clone 后无法直接安装，要么删配置、要么填自己 token，协作链路断裂

正确做法是让 Composer 从本地或环境可信位置读取凭据，且不参与版本控制。

用 `auth.json` 实现用户级凭据隔离

auth.json 是 Composer 官方支持的凭据文件，优先级高于 composer.json 中的内联配置，且默认不被 Git 跟踪（应加入 .gitignore）。

它有两种生效范围：

项目级：./auth.json（仅对当前项目生效，适合临时调试）
全局级：~/.composer/auth.json（对所有项目生效，适合个人开发环境）

示例内容（用于访问私有 Packagist 或付费组件仓库）：

Workflow Decomposer

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

下载

{
    "http-basic": {
        "packages.example.com": {
            "username": "your-license-email@example.com",
            "password": "your-actual-api-token"
        }
    }
}

注意：password 字段实际承载的是 token，不是密码；某些商业组件（如 Laravel Nova）要求用邮箱作 username，token 作 password，顺序不能颠倒。

CI/CD 中安全注入秘钥的实操要点

GitHub Actions、GitLab CI 等平台不支持直接写入 ~/.composer/auth.json，需在 job 中动态生成。关键点在于：

使用平台提供的加密 secrets（如 SECRET_NOVA_TOKEN），绝不在脚本中 echo $TOKEN 或记录日志
生成 auth.json 后立即执行 composer install，避免文件残留
确认私有仓库域名与 auth.json 中的 key 严格一致（含端口、协议前缀都不行）

GitHub Actions 示例片段：

- name: Set up auth.json
  run: |
    mkdir -p ~/.composer
    cat > ~/.composer/auth.json <h3>多个商业组件共存时的域名冲突处理</h3><p>当同时使用 Nova、Spark、Pest 商业版等，它们可能都托管在 <code>https://nova.laravel.com</code>、<code>https://spark.laravel.com</code> 这类独立域名下——这时 <code>auth.json</code> 的 key 就是域名本身，不存在冲突。</p><p>但若多个组件打包在同一个私有仓库（如自建 Satis 或 Private Packagist），而你又为不同客户分配了不同 token，则必须：</p>