私有 git 仓库需在 composer.json 的 repositories 中声明 type 为 vcs 并指定 url，require 中必须使用包内 composer.json 定义的 vendor/name 格式名称，且确保 minimum-stability 匹配分支稳定性（如 dev-main 需设 "minimum-stability": "dev"）。
私有 Git 仓库必须声明为 repository 类型
Composer 默认只认 Packagist 上的公开包，想装自己 Git 仓库里的代码，得先告诉它“这个地址是个合法源”。不是加个 require 就能拉的——composer.json 顶层必须显式写 "repositories"，且类型设为 "vcs"。
常见错误是漏掉 "type": "vcs"，或者把 Git 地址直接塞进 require（比如写成 "my/private-package": "dev-main"），结果报错：Could not find package my/private-package at any version。
-
"repositories"是数组，可同时配多个私有源，顺序无关 - Git 地址支持 HTTPS 和 SSH，但 SSH 需本地已配置好密钥且能
git clone通 - HTTPS 地址若需认证（如公司 GitLab 私有实例），得提前用
git config --global credential.helper store或在 URL 里嵌用户名密码（不推荐）
{
"repositories": [
{
"type": "vcs",
"url": "https://git.example.com/my/private-package.git"
}
],
"require": {
"my/private-package": "dev-main"
}
}
composer require 要带完整 vendor/name
私有包的 "name" 必须和它的 composer.json 里声明的一致，且格式是 vendor/name。不能按目录名或 Git 仓库名随意起——Composer 不会自动推导。
典型翻车场景：仓库叫 internal-utils，但包 composer.json 里写的是 "name": "acme/utils"，结果执行 composer require internal-utils 直接失败，提示找不到包。
- 先确认私有包根目录下的
composer.json有正确"name"字段 - 执行
composer require acme/utils:dev-main，不是internal-utils - 如果私有包没设
"version"，只能用dev-*分支别名，不能写1.0.0
SSH 克隆失败？检查 git 命令能否手动跑通
Composer 底层调用的是系统 git 命令，不是 PHP 自己实现的 Git 客户端。所以只要 git clone 命令在终端里失败，Composer 就一定失败，报错通常是：Failed to execute git clone --mirror... 或 Permission denied (publickey)。
别急着改 Composer 配置，先切到命令行验证基础链路：
- 运行
git clone https://git.example.com/my/private-package.git /tmp/test（HTTPS） - 或
git clone git@git.example.com:my/private-package.git /tmp/test（SSH） - 如果失败，就不是 Composer 的问题，而是网络、权限、Git 配置或防火墙的事
- 特别注意：CI 环境（如 GitHub Actions）默认没配 SSH key，要用
actions/checkout或git config预置凭据
包内依赖冲突？优先用 "minimum-stability": "dev"
私有包如果依赖其他 dev 分支（比如也用了 dev-main），而主项目 stability 默认是 stable，Composer 会直接忽略所有 dev 版本，导致安装中断，报错：Your requirements could not be resolved to an installable set of packages.
这不是版本号写错了，是稳定性策略卡住的。解决方法不是硬升版本，而是调整主项目的稳定级别：
- 在主项目
composer.json顶层加"minimum-stability": "dev" - 同时建议补上
"prefer-stable": true，避免意外装到不稳定的第三方包 - 如果只想对某个私有包放宽限制，可用
"stability-flags"，但维护成本高，一般不必要
私有包的开发节奏快，分支常变，硬锁 stable 只会让协作卡在第一步。
