不能直接用 Composer install 私有 Git 仓库，因需本地配置认证、不支持版本稳定解析与团队复用，必须通过 Satis 等私有 Packagist 实现可发现性与可分发性。
为什么不能直接用 Composer install 私有 Git 仓库？
Composer 默认支持通过 git 协议或 HTTPS 克隆私有仓库，但前提是：你本地已配置好 SSH 密钥或 Git 凭据，且 composer.json 中的 repositories 类型设为 vcs。问题在于——这无法被团队其他成员复用，也不支持版本约束（如 "dev-main" 或 "1.2.0"）的稳定解析，更不提供包搜索、依赖图谱、Web 界面等能力。
真正需要私有 Packagist，本质是解决「可发现性」和「可分发性」：让任意能访问仓库服务的机器，仅靠 composer require vendor/package 就能拉取、缓存、校验、安装。
常见踩坑点：
- 误以为加个
"type": "vcs"到repositories就等于有了私有仓库——这只是临时绕过方案，不是发布流程 - 把 Satis 配置成全量扫描 Git 服务器（如 Gitee/GitLab），结果每次
build都超时或漏包——Satis 不自动发现仓库，必须显式列出packages - 忽略
require和require-dev的作用域差异，导致 Satis 构建时把测试工具也打进 dist 包，体积暴涨
如何用 Satis 搭建最小可用私有仓库？
Satis 是最轻量、最可控的私有 Packagist 替代方案，它不运行服务，只生成静态 packages.json 和 dist 归档，适合内网或 CI/CD 场景。
实操要点：
- 新建
satis.json，核心字段必须包含：name（仓库名）、homepage（输出目录 URL 前缀）、repositories（明确列出每个私有包的 Git 地址）、require-all或require（指定哪些包要纳入索引） - 确保所有私有仓库的
composer.json中有合法version字段（或打 Git tag），否则 Satis 无法识别可用版本 - 执行
php bin/satis build satis.json web/，生成的web/packages.json就是 Composer 能读取的源数据 - 把
web/目录用 Nginx/Apache 托管，确保能通过 HTTP 访问到https://pkgs.your.org/packages.json
示例 satis.json 片段：
