私有 Git 仓库认证失败时，Composer 报错如“Authentication failed for 'https://github.com/...'”或“remote: HTTP Basic: Access denied”，本质是 git clone 被拒绝，而非 Composer 自身鉴权问题；因 Composer 对 vcs 类型仓库仅解析元数据，实际下载由 git 执行，故 auth.json 或 http-basic 配置无效，必须通过 Git 凭据管理器（如 credential.helper）或 URL 内联 token（CI 环境）让 git 自动认证。
私有 Git 仓库认证失败时，Composer 报什么错
执行 composer install 或 composer update 时，如果私有 Git 仓库（如 GitHub、GitLab、自建 Gitea）需要认证但未配置凭据，常见报错是：
Failed to download vendor/package from source: Failed to execute git clone --mirror 'https://git.example.com/vendor/package.git' '/path/to/cache/...'-
remote: HTTP Basic: Access denied（GitLab） -
Authentication failed for 'https://github.com/...'（GitHub）
这类错误本质是 Composer 调用 git 命令拉取代码时被拒绝，不是 Composer 自身的鉴权问题——它只是在转发 Git 的认证请求。
推荐方式：用 Git 凭据管理器（credential helper）而非 Composer 配置
Composer 官方文档曾提过 config http-basic，但它只适用于支持 HTTP Basic Auth 的 Composer Repository（如 Satis、Private Packagist），**不适用于普通 Git 仓库（如 github.com、gitlab.com）**。对 Git HTTPS 地址，必须由 git 自己处理认证。
正确做法是配置 Git 的凭据存储，让 git clone 能自动提供用户名和 token：
- GitHub 推荐用
gh auth login（会自动配置git credential.helper） - GitLab 可运行
git config --global credential.helper store，然后首次手动克隆一次，输入username+Personal Access Token（密码框里填 token，不是密码） - Linux 下可搭配
libsecret，macOS 用osxkeychain，Windows 用manager-core，都比明文存store更安全
验证是否生效：在终端运行 git ls-remote https://github.com/your-org/private-package.git，不报错即成功。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
为什么不要在 composer.json 里写 http-basic 配置私有 Git 仓库
"repositories" 中加 "type": "vcs" 的仓库（如 "url": "https://gitlab.com/group/repo.git"），Composer 仅用它发现 composer.json 并解析版本，**实际下载仍走 git clone**。此时设置：
composer config http-basic.gitlab.com username token
完全无效——因为 http-basic 只影响 Composer 对 packagist.org 类型仓库的 HTTP 请求，不影响底层 git 进程。
唯一适用场景是：你搭建了支持 Basic Auth 的 Composer 仓库服务（如 Satis + Nginx Basic Auth），且把 type 设为 composer，URL 指向它的 packages.json。这种架构下才需要 http-basic。
CI/CD 环境中怎么安全传入凭据
本地开发可用凭据管理器，但 CI（如 GitHub Actions、GitLab CI）必须避免硬编码。关键原则是：让 git 命令能读到 token，而不是让 Composer “知道”密码。
- GitHub Actions：用
actions/checkout@v4默认已注入GITHUB_TOKEN，私有仓库同组织下可直接 clone；跨组织则需在repositoryURL 中内联 token：https://${{ secrets.PERSONAL_TOKEN }}@github.com/org/repo.git（注意提前 URL 编码 token 中的特殊字符） - GitLab CI：设
CI_JOB_TOKEN或PERSONAL_ACCESS_TOKEN为变量，在.gitmodules或composer.json的 repository URL 里拼接，或用git config --global url."https://${TOKEN}@gitlab.com".insteadOf "https://gitlab.com" - 禁止在
composer.json或auth.json里写死 token，尤其不能提交到 Git ——auth.json应该只在部署机上存在，且权限设为600
最易忽略的一点：很多团队以为配了 auth.json 就万事大吉，却没意识到它对 Git HTTPS 拉取毫无作用；真正起效的是 Git 自己的凭据链，而这条链在容器、CI runner、SSH 会话之间常常断开或未初始化。
