如何用Composer管理多个github-oauth令牌？PHP扩展仓库方案咨询

一、多GitHub私有仓库的认证处理 #

Composer全局仅支持配置一个github-oauth令牌，但可以通过仓库级别的认证配置绕过这个限制：

• SSH密钥替代OAuth令牌：在项目composer.json中为每个私有仓库单独配置SSH密钥，无需依赖全局令牌。示例配置：

  {
    "repositories": [
      {
        "type": "vcs",
        "url": "git@github.com:vendor-a/private-ext.git",
        "options": {
          "ssh2": {
            "username": "git",
            "privateKeyFile": "/path/to/vendor-a-ssh-key"
          }
        }
      },
      {
        "type": "vcs",
        "url": "git@github.com:vendor-b/private-ext.git",
        "options": {
          "ssh2": {
            "username": "git",
            "privateKeyFile": "/path/to/vendor-b-ssh-key"
          }
        }
      }
    ]
  }
  

• 使用GitHub Deploy Key：为每个私有仓库创建单独的Deploy Key，权限仅限定该仓库，比个人令牌更安全，也能避免全局令牌的限制。

二、轻量替代Satis的私有仓库方案 #

如果觉得Satis过于臃肿，可选择以下轻量方案：

• 静态文件自建仓库：将所有私有扩展的composer.json信息汇总到一个packages.json文件中，托管在自己的服务器或对象存储上，项目中仅需添加该仓库地址即可。示例：

  {
    "repositories": [
      {
        "type": "composer",
        "url": "https://your-server.com/private-composer-repo/"
      }
    ]
  }
  

  这种方式几乎无维护成本，适合扩展数量不多的场景。
• Toran Proxy：比Satis资源占用更低，既能缓存Packagist公共包，也能托管私有包，部署和维护都很简单，适合中小团队使用。
• Private Packagist免费版：支持3个私有包的免费额度，足够初期整合第三方扩展或售卖自己的少量扩展，无需自建服务。

三、自身售卖扩展的管理建议 #

若计划售卖自己的PHP扩展，可提前做以下规划：

• 用独立的GitHub组织管理所有自有扩展，买家只需配置一个针对该组织的令牌（或Deploy Key），即可访问所有你的扩展，无需逐个包配置认证。
• 搭配轻量私有仓库方案，将自有扩展和第三方扩展统一管理，买家仅需配置一个仓库地址，简化依赖管理流程。

内容的提问来源于stack exchange，提问作者ljr95