根本原因是Composer拉取私有Git仓库时SSH密钥未正确配置或未被识别，需确保git clone能成功、~/.ssh/config绑定正确主机与密钥、CI中SSH agent已加载且权限正确。
Composer 拉取私有 Git 仓库时提示 Permission denied (publickey)
根本原因是 Composer 默认走 HTTPS 或 SSH 协议拉包，而私有仓库若用 SSH 地址（如 git@github.com:org/repo.git），却没配好本地 SSH 密钥或未告知 Git 使用哪个密钥。
常见错误现象：执行 composer install 或 composer update 时卡在 Cloning into ...，然后报 Permission denied (publickey)；或者直接跳过 SSH 走 HTTPS，触发登录弹窗或 401 错误。
- 确认 Git 能手动克隆：
git clone git@github.com:org/repo.git成功，才说明 SSH 密钥本身没问题 - Composer 不读
~/.ssh/config的别名（比如Host gh），必须用完整域名（如github.com）匹配密钥 - 如果用了非默认密钥（比如
id_rsa_private），得在~/.ssh/config里显式绑定：Host github.com IdentityFile ~/.ssh/id_rsa_private
- Windows 用户注意：Git Bash 和 CMD/PowerShell 下的 SSH agent 可能不互通，优先用 Git Bash 执行
composer install
composer.json 里写 SSH 地址后仍走 HTTPS
Composer 会自动把 SSH URL（git@host:path.git）转成 HTTPS 再尝试，尤其当仓库平台（如 GitHub、GitLab）支持两种协议时 —— 这是它的默认降级逻辑，不是 bug。
要强制走 SSH，必须在 composer.json 中明确指定 vcs 类型，并关闭 HTTPS 回退：
- 在
repositories里声明为vcs，且 URL 以git@开头："repositories": [ { "type": "vcs", "url": "git@github.com:org/private-package.git" } ] - 确保该仓库的
composer.json里name字段与require中一致，否则 Composer 会忽略这个源 - 删掉
vendor/和composer.lock后重装，避免缓存旧的 HTTPS 元数据
多私有仓库共存时 SSH 密钥冲突
一个机器连多个 Git 平台（比如 GitHub + GitLab + 自建 Gitea），各自用了不同密钥，但 SSH 默认只认 id_rsa，容易串库或认证失败。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
解决核心是让 Git 知道“对哪个域名用哪把密钥”，靠 ~/.ssh/config 分流：
- 每段
Host必须和仓库 URL 中的主机名完全一致（如gitlab.example.com，不能写gitlab） -
User字段填git（所有 Git 托管平台 SSH 入口用户都是git） - 示例配置：
Host github.com User git IdentityFile ~/.ssh/id_rsa_github Host gitlab.example.com User git IdentityFile ~/.ssh/id_rsa_gitlab
- 配置完运行
ssh -T git@github.com测试是否命中对应密钥
CI 环境（GitHub Actions / GitLab CI）中配置失败
本地能跑通，CI 上却拉不到 —— 大部分因为 CI runner 没加载 SSH agent，或密钥没正确注入。
关键点不在 Composer 配置，而在环境初始化：
- GitHub Actions：用
webfactory/ssh-agentAction 注入密钥，且必须在composer install步骤前运行 - GitLab CI：把私钥存为
CI/CD Variables（变量名如SSH_PRIVATE_KEY），并在 job 中写入~/.ssh/id_rsa并设权限：chmod 600 ~/.ssh/id_rsa - 无论哪种 CI，都要确认
~/.ssh/config已存在并指向正确密钥，否则 Git 不知道该用谁 - 避免在
composer.json中硬编码dev-master分支 —— CI 缓存可能拉到旧 commit，建议用稳定 tag 或加"minimum-stability": "dev"显式控制
私有仓库的 SSH 路径、密钥绑定、CI 权限三者只要漏一环，就会静默失败。最省事的排查顺序：先手动 git clone，再看 Composer 是否复用同一套 SSH 配置，最后检查 CI 的密钥加载时机。
