在单台云服务器上低成本运行Composer私有仓库-composer-PHP中文网

选satis因其轻量高效：仅需php+git+web服务器，512mb小主机即可运行；而artifactory需jvm且配置复杂，packagist不支持私有包。关键要配对satis.json的repositories、require包名及archive路径，并在项目composer.json中设"packagist.org":false且确保packages.json可curl通。

在单台云服务器上低成本运行composer私有仓库

直接用 Satis 就够了，不需要 Artifactory 或 Harbor——后者是给 Docker 镜像用的，和 Composer 包无关；前者重量级、带 UI、要 Java 运行时，单台云服务器上纯属杀鸡用牛刀。

为什么选 Satis 而不是 Packagist 或 Artifactory

Satis 是 Composer 官方推荐的轻量私有仓库方案，本质是一个静态站点生成器：它拉取你指定的 Git 仓库（如 GitHub/GitLab 私有库），解析其中 composer.json，生成 packages.json 和归档包（tar/zip），全部文件可直接扔进 Nginx 或 Apache 目录里访问。

对比其他方案：

Artifactory：需 JVM、内存占用常超 1GB，配置复杂，repositories 类型必须为 composer，否则报 Invalid repository type
Packagist.org：无法托管私有包，且默认源不关闭就会覆盖你的私有配置
自建 API 服务（如 Private Packagist）：需维护 PHP-FPM + 数据库 + 权限系统，运维成本陡增

而 Satis 只依赖 PHP CLI + Git + 一个 Web 服务器，512MB 内存的小型云服务器完全扛得住。

关键配置项：satis.json 必须写对的三处

satis.json 是 Satis 的核心配置文件，漏掉或写错任意一项都会导致 composer update 找不到包。重点关注以下三点：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

"repositories" 数组里必须是 "type": "vcs"，指向你的 Git 地址，例如 "https://gitlab.example.com/team/lib-a.git" ——不能写成 "type": "package" 或漏掉协议头
"require" 中的包名必须与目标仓库 composer.json 里的 "name" 字段**完全一致**，包括大小写和 vendor 名，比如 "acme/utils" 写成 "Acme/utils" 就会静默失败
"archive" 下的 "directory" 必须存在且 Web 服务器有读权限；"format" 推荐设为 "tar"（比 zip 更兼容旧版 Composer）；"skip-dev" 设为 true 可避免生成 dev-master 等不稳定归档

项目 composer.json 怎么配才不 fallback 到 packagist.org

很多人加了私有仓库 URL 却仍报 Could not find package vendor/name，根本原因不是 URL 错，而是没关默认源。必须在项目级 composer.json 中显式禁用：

{
  "repositories": [
    {
      "type": "composer",
      "url": "https://satis.example.com/"
    }
  ],
  "packagist.org": false
}

注意："packagist.org": false 这一行不能省，且必须是顶层字段（和 repositories 同级）；url 值末尾的斜杠 / 也不能少，否则 Nginx 返回 404，Composer 会自动 fallback 并不报错。

部署后 curl 不通 packages.json 就等于白搭

Satis 生成的是纯静态文件，没有后台服务。如果 composer update 仍走外网，第一件事就是手动验证：

执行 curl -I https://satis.example.com/packages.json，必须返回 HTTP 200，不是 403/404/302
检查 Nginx 配置是否限制了 .json 文件的 MIME 类型（应为 application/json）
确认 packages.json 文件权限为 644，且所在目录可被 Web 用户（如 www-data）读取
若用 Let’s Encrypt，确保证书未过期——过期证书会导致 Composer TLS 握手失败并静默跳过该源

所有路径、协议、权限、证书状态，任何一个环节断掉，Composer 都不会明确提示，只会默默回退到 packagist.org 查找，这是最隐蔽也最常被忽略的问题点。