Composer报“包不存在”常因SSH连接失败导致元数据读取中断，须先执行ssh -T git@your-gitlab-domain.com验证连通性；若失败，需检查~/.ssh/config中Host、HostName、Port、IdentityFile是否与仓库URL完全匹配，并确保SSH agent已启动且密钥已加载。
确认 Composer 能否通过 SSH 访问 GitLab
Composer 报“包不存在”，实际常是 SSH 连接失败导致无法读取仓库元数据，而非包真不存在。先绕过 Composer，直接测试 SSH 连通性：
ssh -T git@your-gitlab-domain.com如果提示
Permission denied (publickey) 或超时，说明密钥没配好或没加载。注意：这里的 git@your-gitlab-domain.com 必须和 composer.json 中仓库 URL 的主机名完全一致（比如 git@gitlab.internal ≠ git@gitlab.internal:2222），否则 SSH 配置不生效。
检查 ~/.ssh/config 是否匹配 GitLab 域名和端口
内网 GitLab 常用非标端口（如 2222）或自定义域名，~/.ssh/config 必须显式声明对应 Host 别名。常见遗漏点：
- Host 条目写成
Host gitlab.internal，但仓库 URL 是git@gitlab.internal:2222/...—— SSH 默认不识别端口在 URL 中的写法，必须用Host+Port显式绑定 - 私钥路径写错，比如用了
id_rsa但实际是id_ed25519 - 漏掉
IdentityFile或IdentitiesOnly yes，导致 SSH 尝试了错误密钥后放弃
Host gitlab.internal<br> HostName gitlab.internal<br> Port 2222<br> User git<br> IdentityFile ~/.ssh/id_gitlab<br> IdentitiesOnly yes
验证 Git 是否能 clone 同一仓库
Composer 底层调用 Git，如果 Git 本身 clone 失败，Composer 必然失败。执行：
git clone git@gitlab.internal:group/project.git /tmp/test-clone观察是否卡住、报
fatal: Could not read from remote repository 或权限拒绝。若成功，说明 SSH 配置没问题，问题可能出在：
-
composer.json中仓库 URL 写成了 HTTPS（如https://gitlab.internal/group/project.git），而内网 GitLab 关闭了 HTTPS 访问 - 仓库设置了 private visibility，但当前用户无访问权限（需登录 GitLab 网页确认该账号是否被授予项目成员）
- Composer 缓存了旧的失败响应，运行
composer clear-cache再试
让 Composer 强制走 SSH 并显示详细过程
默认情况下 Composer 可能尝试 HTTPS fallback，掩盖真实 SSH 问题。强制指定 VCS 类型并开调试：
composer install -vvv --repository-url=git@gitlab.internal:group/project.git注意：
--repository-url 参数值必须是完整 SSH URL（含 git@ 和冒号分隔路径）。-vvv 会打印 Git 克隆命令和 stderr 输出，关键线索常藏在类似 Cloning into '/path/to/vendor/...'... 后面的错误行里，比如 fatal: unable to access 'git@gitlab.internal:...': Failed to connect to gitlab.internal port 22: Connection refused —— 这说明端口不通，不是密钥问题。
内网环境最容易被忽略的是：SSH agent 没启动，或者终端 session 没加载 agent 环境变量（SSH_AUTH_SOCK 为空），导致 ssh-add -l 看得见密钥，但 Composer 启动的子进程看不见。
