私有包源配置不能硬编码在composer.json中，因不同环境需差异化认证且易泄露敏感信息；应通过composer_auth环境变量或auth.json文件配合composer_home动态注入凭证，并确保repositories声明与认证域名严格一致。
私有包源配置为什么不能直接写死在 composer.json 里
因为团队协作或 CI/CD 场景下，不同环境（开发、测试、生产）的私有仓库地址、认证方式往往不同。硬编码在 composer.json 中会导致提交敏感信息（如 token）、配置冲突或无法复用。Composer 明确推荐用环境变量 + auth.json 或命令行注入的方式解耦。
用 COMPOSER_AUTH 环境变量注入认证信息
这是最轻量、CI 友好的方式，尤其适合 GitLab CI、GitHub Actions 等场景。Composer 会自动读取该变量内容并当作 auth.json 解析。
-
COMPOSER_AUTH的值必须是合法 JSON 字符串，且顶层为对象 - 需转义双引号，常见写法：
export COMPOSER_AUTH='{"http-basic":{"packages.example.com":{"username":"token","password":""}}}' - 若使用 token 认证（如 GitHub Packages），
username填 token，password留空或填任意值（部分服务要求非空，可填x-oauth-basic） - 注意：该变量只影响当前 shell 会话；CI 中建议在 job 步骤开头
export，或通过平台 secret 注入
用 auth.json 文件配合 COMPOSER_HOME 切换路径
当需要多套凭据（比如本地开发用 SSH key，CI 用 token），靠单个环境变量不够灵活，这时应配合 COMPOSER_HOME 指向不同配置目录。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 默认
auth.json在$HOME/.composer/auth.json，但可通过COMPOSER_HOME=/path/to/composer-home composer install覆盖 - 例如：开发机上
/opt/composer-dev/auth.json放 SSH 配置，CI 中挂载/tmp/composer-ci/auth.json放 token -
auth.json内容示例：{"http-basic": {"gitlab.example.com": {"username": "gitlab-ci-token", "password": "glpat-xxxxx"}}} - 务必确保
auth.json文件权限为600（chmod 600 auth.json），否则 Composer 会拒绝加载
私有源声明必须用 repositories，且类型要匹配协议
composer.json 中的 repositories 是静态声明，它不处理认证，只告诉 Composer “去哪找包”。认证由前述机制单独提供。
- HTTP(S) 私有 Packagist：用
"type": "composer"，URL 必须以/结尾（如"url": "https://packages.example.com/"） - Git 仓库（如 GitHub/GitLab 私有库）：用
"type": "vcs"，URL 填完整 Git 地址（"url": "https://gitlab.example.com/group/pkg.git"） - 不要在
repositories中写用户名密码（如https://user:pass@...），现代 Composer 版本会忽略甚至报错 - 若私有源本身启用了 Basic Auth（如 Nexus Repository），那它属于「源服务器层面的认证」，仍需通过
COMPOSER_AUTH或auth.json提供凭证
真正容易被忽略的是：Composer 不会主动校验 auth.json 里声明的域名是否和 repositories 中的 URL 域名完全一致——大小写、端口、子域名差异都会导致认证失败且错误提示极不明确（常表现为 401 或 Could not fetch）。检查时务必逐字比对 https://packages.example.com 和 auth.json 里的 "packages.example.com"。
