Composer如何使用JFrog Artifactory作为企业私有仓库源（集成方案）-composer-PHP中文网

需在artifactory创建原生composer类型仓库（本地/远程/虚拟），url含/api/composer/且末尾带斜杠；项目composer.json中声明type为composer的仓库url，并显式设置"packagist.org": false禁用默认源；私有包须按vendor/name命名并用composer publish或api上传，认证通过auth.json配置且路径正确。

composer如何使用jfrog artifactory作为企业私有仓库源（集成方案）

如何配置 Composer 使用 Artifactory 的 Composer Repository

Artifactory 支持原生 Composer 仓库类型（composer），不是靠代理或通用仓库模拟的。必须在 Artifactory 后台创建一个类型为 composer 的本地或远程仓库，而非用 generic 或 remote 伪装——否则 composer install 会因元数据格式不兼容直接失败。

创建后，仓库 URL 形如 https://artifactory.example.com/artifactory/api/composer/my-composer-repo/（注意末尾斜杠不能少，且路径含 /api/composer/）。

本地仓库用于托管内部包（packagist.org 不收录的私有 vendor/name）
远程仓库可代理 packagist.org，减少外网依赖并缓存
虚拟仓库可聚合本地 + 远程，作为统一入口供 Composer 使用

为什么 `composer.json` 中的 `repositories` 配置容易出错

Composer 默认只认 packagist.org，要切换源，必须显式覆盖。常见错误是把 Artifactory 地址写进 repositories 却没禁用 Packagist，默认行为仍是“先查 Packagist 再 fallback”，导致私有包根本不会被扫描。

正确做法是在项目级 composer.json 中声明：

{
  "repositories": [
    {
      "type": "composer",
      "url": "https://artifactory.example.com/artifactory/api/composer/my-virtual-repo/"
    }
  ],
  "packagist.org": false
}

"packagist.org": false 是关键——它彻底关闭默认源，强制所有包都走 Artifactory。漏掉这行，私有包安装时会报 Could not find package vendor/name，即使该包确实存在于 Artifactory 中。

如何让私有包能被 `composer require` 正确解析

Artifactory 不会自动索引你上传的 ZIP 或 TAR 包。私有包必须满足两个条件才能被发现：

Discussion Composer

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

下载

包的 composer.json 中 name 字段格式为 your-company/package-name（带 vendor 前缀）
上传方式必须用 Artifactory 的 composer 仓库专用 API，或通过 composer publish（需配置 auth.json）；直接 Web UI 上传 ZIP 文件无效

推荐使用命令行发布：

composer publish --repository=https://artifactory.example.com/artifactory/api/composer/my-local-repo/

执行前确保 auth.json 已配置对应仓库的 API Key 或用户名密码，否则返回 401 Unauthorized。

认证失败时排查哪几个点

最常见的 401 或 403 并非密码错，而是权限链断裂：

auth.json 路径不对：必须放在 COMPOSER_HOME 目录下（通常是 ~/.composer/auth.json），项目根目录下的 auth.json 不会被读取
Artifactory 用户缺少 deploy 权限（发布）或 read 权限（安装），仅给 manage 不够
仓库配置了匿名访问限制，但请求头未携带认证信息——Composer 会自动读 auth.json，但如果该文件格式非法（如多了一个逗号），就会静默跳过认证

验证方式：用 curl -u user:apikey -X GET "https://artifactory.example.com/artifactory/api/composer/my-repo/packages.json" 手动测试是否返回 JSON 列表。不成功，就不是 Composer 的问题，而是 Artifactory 端权限或网络策略卡住了。

Artifactory 的 Composer 集成不是“配完 URL 就能跑”，每层权限、每个 URL 路径细节、每处 JSON 格式都可能成为断点。尤其要注意 /api/composer/ 这段路径和末尾斜杠——少一个字符，整个流程就停在 404。