VCS不是指令而是版本控制系统统称，代表协同开发、代码存档与历史追溯的方法论及工具集合；它不提供“vcs”命令，而是包含Git、SVN等具体实现，核心解决多人并行、回退定位与协作边界问题。
能，而且完全不需要运维服务器或写后端代码。用 satis 生成静态文件 + 任意 HTTP 服务（甚至 GitHub Pages、Nginx、Apache、Python -m http.server）就能跑起来。
为什么不用 VCS 直接拉私有 Git 仓库？
直接在项目 composer.json 里加 "type": "vcs" 确实最简单，但问题很实际：
- 每次
composer install都要走一遍 Git clone/fetch，网络抖动或权限失效就卡住 - 无法统一控制包版本可见性（比如只允许
1.2.*，不暴露dev-feature分支） - 没有元数据缓存，
composer show查不到私有包信息，IDE 自动补全弱 - 多人协作时，每人本地 Git 凭据配置不一致，CI 构建容易失败
satis.json 最小可用配置长什么样？
三要素必须齐：name、homepage、repositories。别漏掉 require-all 或 require，否则生成的 packages.json 是空的 —— 这是构建后 composer require 找不到包的最常见原因。
示例（保存为 satis.json）：
{
"name": "My Private Packages",
"homepage": "https://packages.internal",
"repositories": [
{"type": "vcs", "url": "https://gitlab.com/team/utils"}
],
"require-all": true
}
注意：homepage 必须是最终部署后的可访问 URL（哪怕只是 http://localhost:8000），它会写进每个包的 dist.url 字段；url 指向 Git 仓库根目录（含 composer.json 的那个地址），不要带 .git 后缀。
客户端项目怎么连上你的私有源？
不是改私有包自己的 composer.json，而是改「要装这个包的那个项目」的顶层 composer.json：
- 必须显式声明
"type": "composer"的源，URL 指向你部署satis输出目录的根路径（比如http://packages.internal） - 必须禁用 Packagist 默认源，否则同名包会被优先从公网下载：
"packagist.org": false - 顺序很重要：多个私有源时，靠前的先匹配，同名包后面的直接忽略
示例片段：
{
"repositories": [
{
"type": "composer",
"url": "https://packages.internal"
}
],
"packagist.org": false,
"require": {
"team/utils": "^2.1"
}
}
auth.json 是唯一合法凭据载体，且权限必须是 600
如果你的 Git 仓库需要认证（GitLab 私有项目、GitHub PAT、自建 HTTPS Git），凭据绝不能塞进 satis.json 或 URL 里。Satis 构建时会读取系统级 auth.json（通常在 ~/.composer/auth.json），且该文件权限必须为 600，否则 Composer 直接拒绝加载。
正确写法（~/.composer/auth.json）：
{
"http-basic": {
"gitlab.com": {
"username": "your-token-name",
"password": "glpat-xxxxxxxxxxxxxxxxxxxx"
}
}
}
运行 chmod 600 ~/.composer/auth.json，漏掉这步，satis build 会静默跳过所有需认证的仓库，生成的 packages.json 里根本没那些包。
真正麻烦的不是搭建，而是维护：satis 不支持增量更新，每次都要全量 rebuild；包的 version 字段若写成 dev-main 或 1.0.x-dev，默认不会被收录（require-all 只收带规范语义化版本的 tag）；dist ZIP 文件没生成，composer install 就会自动回退到 source 方式，又变慢又依赖 Git 权限 —— 这些细节不盯住，私有源就只是个摆设。
