Composer怎么使用企业私有仓库？多项目共享包配置方法-composer-PHP中文网

项目级配置是唯一可靠方案，因全局配置不进git、ci环境缺失、多项目认证无法隔离，且repositories必须为顶层数组、顺序决定匹配逻辑，私有源需放前并显式添加packagist.org。

composer怎么使用企业私有仓库？多项目共享包配置方法

直接在项目级 composer.json 里写死 repositories 并设 "packagist.org": false，是唯一可靠、可版本控制、CI 友好的做法。全局配置或手动改 ~/.composer/config.json 在团队协作中必然失效。

为什么不能用 `composer config --global` 配私有源

全局配置写入 ~/.composer/config.json，它不进 Git，不同成员机器上内容不一致；CI 环境（如 GitHub Actions）默认没这个文件，composer install 会直接报 Could not find package；更隐蔽的是：一旦某人执行 composer config --global --unset repositories.xxx，整个本地环境就断连，且无日志提示哪一行配错了。

CI 脚本若依赖全局源，必须额外加 composer config --global 步骤，增加失败点
多个项目共用同一私有源，但各自需要不同认证域（比如 A 项目连 Artifactory，B 项目连 GitLab），全局 auth.json 无法按项目隔离
composer config --global 设置的仓库，在 composer show -p 中可见，但 composer update -v 日志里不会显示实际请求了哪个源——排查 401/404 时毫无头绪

`repositories` 必须是顶层数组，且顺序决定匹配逻辑

Composer 不会递归扫描字段，repositories 必须出现在 composer.json 最外层，嵌套在 config 或 extra 里等于没写。它按数组顺序逐个检查，命中即停，不回退。

Discussion Composer

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

下载

私有源要放前面，否则 your-company/utils 可能被误路由到 packagist.org 找不到而报错
如果同时用 Artifactory 虚拟源和 Satis 静态源，两者都设 "type": "composer"，但 URL 格式不同：https://artifactory.example.com/artifactory/api/composer/my-virtual/（末尾斜杠必有），而 Satis 是 https://packages.example.com/（通常无 /api/composer/）

必须显式把 packagist.org 加回来，除非你确认所有依赖都在私有源里：

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

注意："packagist.org": false 关闭的是隐式源，不是数组里的那个显式项

私有包能被 `require` 到的关键条件

光把仓库 URL 写对还不够。Artifactory 和 Satis 对“包可见性”的要求完全不同，但都卡在三个硬性点上。

包的 composer.json 中 name 字段必须是 vendor/name 格式，且与 composer require vendor/name 完全一致——大小写、中划线、下划线都不能差一个字符
Artifactory 要求上传必须走其 Composer API 或 composer publish，Web UI 上传 ZIP 文件无效；Satis 则必须靠 php bin/satis build 扫描 VCS 仓库生成 packages.json，且 satis.json 中 repositories 的 URL 必须带 .git 后缀（如 https://gitlab.example.com/team/pkg.git）
认证必须透传：Artifactory 用 ~/.composer/auth.json 里的 http-basic 域名键精确匹配（如 URL 是 https://artifactory.example.com:8443/...，key 就得是 "artifactory.example.com:8443"）；GitLab 则必须用 oauth2 用户名 + glpat- 开头的 Token

CI/CD 中 auth.json 的路径和权限容易被忽略

CI 环境里 ~/.composer/auth.json 不是自动存在的，且权限错误会导致认证静默失败——composer install 不报错，但所有私有源请求都返回 401，日志里也看不到 Authorization 头。

Linux/macOS 下必须 chmod 600 ~/.composer/auth.json，否则 Composer 直接跳过读取

GitHub Actions 示例：

- name: Setup auth.json
  run: |
    mkdir -p ~/.composer
    echo '${{ secrets.COMPOSER_AUTH }}' > ~/.composer/auth.json
    chmod 600 ~/.composer/auth.json

其中 COMPOSER_AUTH 是预存的 JSON 字符串，不是文件路径